[#3-12]BGP Advertise-map을 활용한 DR 구성

이번시간에는 BGP의 기본기능인 Advertise-map을 알아보면서, 이를 활용하여 DR 환경을 제 나름대로 구성해보고자 합니다.

 

우선 DR에 대한 정의를 명확히 하자면, 재해 복구(Disaster Recovery, DR)를  의미하며, 

IT에서는 Network 뿐만 아니라 서버의 DR, Database의 DR 등과 같이 재난 상황에서 서비스 연속성을 보장하기 위한 일련의 조치들이 모두 포함됩니다. 

많은 회사에서 이런 DR 체계가 구축되어있고, 실제 상황에서는 프로세스에 따라 DR이 이뤄질겁니다. 

쉽게 말해 재해라고 불릴만한 대형 장애가 났을때, 어떻게 복구를 할까에 대한 내용입니다. 

 

어떻게 DR을 하는지는 다양하겠지만, 온전히 Network단에서 '이렇게도 DR할 수 있다!'를 한번 설명할까합니다. 

Advertise-map을 활용해서요. 

 

* 사용방법에 대해 구체적으로 설명하기 앞서, Advertise-map은 filtering을 위함이 아님을 미리 말씀드립니다.

Peer에게 광고하는 대역에 대한 단순한 Filtering은 굳이 advertise-map을 사용하지않고,

Route-map을 활용하면 됩니다. 

 

BGP에서 기본적으로 'Conditional advertisement'라는 '조건부 광고'기능이 있습니다.  

조건부 광고를 하기위해서 advertise-map을 사용하고 사용방법에는 2가지가 있습니다. 

1) '어떤 Prefix'가 라우팅 테이블에 없을 때, X 라는 대역을 광고할건지, (non-exist-map)

2) '어떤 Prefix'가 라우팅 테이블에 있을 때, X 라는 대역을 광고할건지, (exist-map)

 

이렇게 2개입니다. 

 

'조건부' 라는 내용은 네트워크에서 경험하기 어려운 개념입니다. 

물론 이럴때는 이렇고 저럴때는 저렇다! 정의하는것은 다양하지만, 이는 조건이 아니라 개념에 관한 내용이 태반이니까요.

ex) ip route 0.0.0.0 0.0.0.0 e0/1 10.10.10.1 이라면 e0/1 인터페이스가 살아있을때만 라우팅 테이블에 올라가라! 이고,

e0/1이 Down되었을때에 대한 조치는 다른 라우팅을 명시해줘야지만 하는것처럼요. 

 

다시 advertise-map에 대한 내용으로 돌아와서, 위에 설명한 내용에 대해 프로그래밍 형식으로 살펴보겠습니다. 

 

1) non-exist-map 활용 

 

if '어떤 prefix' in Routing-table:

    then remove 'X' in advertise-list

elif '어떤 prefix' not in Routing-table:

    then add 'X' to advertise-list

 

2) exist-map 활용

 

if '어떤 prefix' in Routing-table:

    then add 'X' to advertise-list

elif '어떤 prefix' not in Routing-table:

    then remove 'X' in advertise-list

 

BGP에서 Peer한테 Prefix를 광고를 해주기위해서는 기본적으로 라우팅 테이블(BGP 테이블 X)에 있어야합니다. 

따라서 'X'라는 Prefix는 이미 라우팅 테이블에 있는 상황이고, 특이사항이나 별도의 route-map이 걸려있지 않은 이상, 

network선언을 해준다면 Peer에 광고되는 대역에 포함됩니다.

 

다만 위에 개념도와 같이, 특정 대역에 대해 라우팅이 존재하거나, 존재하지않거나 하는 조건으로 광고 하냐, 마냐가 정해지는 개념이지요.

이게 다른 IGP에도 존재하는지는 알 수 없으나, 특이한 개념이라고 생각합니다.

 

그렇다면 어떻게 이런 BGP의 특성을 이용하여 Network단에서의 DR을 구성할 수 있는지 천천히 살펴보겠습니다. 

언제나 그랬듯, 구성도를 보고 시나리오에 대해서 설명하겠습니다. 

 

1. 구성도 

 

 

2. 시나리오 

 

당신은 'Center'와 'Site'의 네트워크를 관리하는 엔지니어입니다. 

센터와 사이트에는 Client에게 Public 서비스를 제공하고 있으며,

센터와 사이트는 모두 고정된 BW를 제공하는 회선이 보는바와 같이 설치되어있습니다. 

 

그런데 'Site'에 설치된 ISP3의 인터넷 회선의 품질이 좋지않으며 어쩔때는 몇주씩 Down이여서,

Client로부터 많은 Complain이 발생하고 있는 상황입니다. 

해결책의 일환으로 Serverfarm L3 스위치간 종량제 회선을 설치하였고 아직 설정 전입니다. 

종량제 회선이기때문에 평소에는 사용하지않다가, ISP3회선이 좋지않아 BGP연결 혹은 인터페이스가 끊어질경우,

Center를 통해 Public service인 '6.6.6.6'를 제공해야하는 상황입니다. 

고객은 DR상황에 사람의 개입을 최소화하고 싶어하며, 자동으로 서비스할 수 있는 방안을 모색해야는게 오늘의 시나리오입니다. 

 

 

3. 기본 Config

 

*이번에는 장비가 많아서, ISP와 ISP 외 Confi로 구분하겠습니다. 

 

1) ISP config

ISP0	ISP1	ISP2	ISP3
no ip domain lookup	no ip domain lookup	no ip domain lookup	no ip domain lookup
line con 0	line con 0	line con 0	line con 0
privili level 15	privili level 15	privili level 15	privili level 15
int e0/0	int e0/0	int e0/0	int e0/0
no switchport	no switchport	no switchport	no switchport
ip address 192.168.100.1 255.255.255.0	ip address 10.10.10.2 255.255.255.0	ip address 20.20.20.2 255.255.255.0	ip address 30.30.30.2 255.255.255.0
int e0/1	int e0/1	int e0/1	int e0/1
no switchport	no switchport	no switchport	no switchport
ip address 10.10.10.1 255.255.255.0	ip address 1.1.1.1 255.255.255.0	ip address 2.2.2.1 255.255.255.0	ip address 3.3.3.1 255.255.255.0
int e0/2	router bgp 1	router bgp 2	router bgp 3
no switchport	neighbor 10.10.10.1 remote-as 123	neighbor 20.20.20.1 remote-as 123	neighbor 30.30.30.1 remote-as 123
ip address 20.20.20.1 255.255.255.0	neighbor 1.1.1.2 remote-as 555	neighbor 2.2.2.2 remote-as 555	neighbor 3.3.3.2 remote-as 777
	neighbor 1.1.1.2 default-originate	neighbor 2.2.2.2 default-originate	neighbor 3.3.3.2 default-originate
int e0/3
no switchport
ip address 30.30.30.1 255.255.255.0
router bgp 123
neighbor 10.10.10.2 remote-as 1
neighbor 20.20.20.2 remote-as 2
neighbor 30.30.30.2 remote-as 3

 

2) Non-ISP config

 

CenterA	CenterB	ServerfarmA	Site	ServerfarmB
no ip domain lookup	no ip domain lookup	no ip domain lookup	no ip domain lookup	no ip domain lookup
line con 0	line con 0	line con 0	line con 0	line con 0
privili level 15	privili level 15	privili level 15	privili level 15	privili level 15
int e0/0	int e0/0	int e0/0	int e0/0	int e0/0
no switchport	no switchport	switchport access vlan 1	no switchport	switchport access vlan 1
ip address 1.1.1.2 255.255.255.0	ip address 2.2.2.2 255.255.255.0	swichport mode access	ip address 3.3.3.2 255.255.255.0	swichport mode access
int e0/1	int e0/1	int e0/1	int e0/1	int vlan 1
no switchport	no switchport	switchport access vlan 1	no switchport	ip address 192.168.120.2 255.255.255.0
ip address 192.168.110.2 255.255.255.0	ip address 192.168.110.3 255.255.255.0	swichport mode access	ip address 192.168.120.1 255.255.255.0
				router eigrp 555
int e0/2	int e0/2	int vlan 1	router bgp 777	no auto-sumamry
no switchport	no switchport	ip address 192.168.110.4 255.255.255.0	neighbor 3.3.3.1 remote-as 3	network 192.168.120.0 0.0.0.255
ip address 192.168.0.1 255.255.255.0	ip address 192.168.0.2 255.255.255.0		redistribute eigrp 555	network 6.6.6.6 0.0.0.0
		int lo0	network 3.3.3.0 mask 255.255.255.0
router bgp 555	router bgp 555	ip address 8.8.8.8 255.255.255.255
neighbor 1.1.1.1 remote-as 1	neighbor 2.2.2.1 remote-as 2		router eigrp 555	int lo0
neighbor 192.168.0.2 remote-as 555	neighbor 192.168.0.1 remote-as 555	router eigrp 555	no auto-sumamry	ip address 6.6.6.6 255.255.255.255
neighbor 192.168.0.2 next-hop-self	neighbor 192.168.0.1 next-hop-self	no auto-sumamry	network 192.168.120.0 0.0.0.255
redistribute eigrp 555	redistribute eigrp 555	network 192.168.110.0 0.0.0.255	redistribute bgp 777 metric  10000 50000 255 1 1500 route-map default
		network 8.8.8.8 0.0.0.0
			ip access-list standard 1
			permit 0.0.0.0
router eigrp 555	router eigrp 555
no auto-summary	no auto-summary		route-map default permit 10
network 192.168.110.0 0.0.0.255	network 192.168.110.0 0.0.0.255		match ip address 1
redistribute bgp 555 metric  10000 50000 255 1 1500 route-map default	redistribute bgp 555 metric  10000 100000 255 1 1500 route-map default
ip access-list standard 1	ip access-list standard 1
permit 0.0.0.0	permit 0.0.0.0
route-map default permit 10	route-map default permit 10
match ip address 1	match ip address 1

Config를 하다가 추가로 안 사실은 EIGRP에 eBGP를 redistribute시켜줄때,

'redistribute bgp xxx'만 하면 안되고, 'redistribute bgp  xxx metric x x x x x'를 해줘야만 하네요.

 

기본 Config에 대해 설명을 해보자면, 'Center'나 'Site' 모두 내부에는 EIGRP가 돌고있고, ISP와의 연결은 eBGP로 되어있습니다. 

CE의 BGP로부터 광고받은 대역을 EIGRP를 통해 내부 L3로 전파하나, L3에서는 default routing만을 수용하도록 ACL이 설정된 상태입니다. 

 

 

다시 본론으로 돌아와서, 일단 위와 같이 설정한 상태로 센터와 사이트에서 BGP 광고받는 대역과, 광고하는 대역을 살펴보겠습니다. 

 

* CenterA의 Advertised-routes & routes

 

 

 

* CenterB의 Advertised-routes & routes

 

 

* Site의 Advertised-routes & routes

 

 

물론 ISP에서는 특정 사이트에서 광고하는 Public 대역을 모두 광고하지는 않고, Default routing만 광고를 해주긴 할껀데, 

본 예에서는 MPLS처럼 전용망처럼 작성을 했으니 양해부탁드립니다. 

 

위 출력값을 보면 Center와 Site와 advertised-routes 부분에서 차이점이 있는데,

이는 Serial 대역에 대해서 광고를 해주냐 마냐의 차이가 있습니다. 

Site 대역의 Serial 대역은 3.3.3.0/24이며, Site에서만 광고를 해준 이유는 이를 조건(혹은 매개체, Trigger)으로 삼기위함입니다. 

 

우리는 단순하게 회선이 Down되었을때의 Take-over를 논하는 것이 아닌, DR 즉 재난상황에 대한 논의를 하고 있는 상황으로, 

적어도 DR상황이라면 인터넷 관문라우터는 기본적으로 Down되는 상황이라고 생각했고,

이를 조건으로 삼기 위해 3.3.3.0/24의 대역을 이용했습니다. 

실제로는 이런 방식이 아닌, 이게 죽으면 DR 상황이라고 판단할 수 있는 Prefix를 센터에 Loopback으로 만들어놓아도 괜찮겠습니다. 

 

정상적으로 서비스를 제공중인지 확인하기 위하여, Client에서 각 서비스(8.8.8.8, 6.6.6.6)에 대해 Pingtest로 점검하였습니다. 

 

 

어느 회선도 Down되지 않았을때, Client입장에서는 ServerfarmA나 ServerFarmB에서 제공하는 서비스에는 이상이 없습니다. 

 

아직 DR용 회선에 대해서 별도의 Config를 해놓지않았기때문에 Site의 인터넷을 Down시킨다면, 6.6.6.6에 대한 서비스는 중지될 겁니다. 따로 해보지않아도 결과를 알기에 결과값 캡쳐는 생략하겠습니다. 

 

그럼 Config의 순서를 한번 말로 정의를 해보고 작성해보겠습니다. 

작성된 순서는 최대한 서비스에 지장이 없게끔 순서를 고려하였으나, 충분한 Downtime이 주어진다면 순서는 크게 중요하지 않습니다. 

 

1. 조건부 광고될 라우팅과 조건 Prefix 특정 

 

Center입장에서 우선 3.3.3.0/24를 ISP로부터 받지못하는 상황에서는 본인이 6.6.6.6/32를 광고해야합니다. 

따라서 아래와 같습니다. 

 

조건부 광고될 라우팅 = 6.6.6.6/32 

조건 Prefix = 3.3.3.0/24

 

이를 route-map으로 표현해보았고, CenterA와 CenterB에 모두 적용하겠습니다. 

 

ip prefix-list DR permit 6.6.6.6/32

 

route-map DR permit 10 

 match ip address prefix-list DR

 

ip prefix-list condition permit 3.3.3.0/24

 

route-map condition permit 10

 match ip address prefix-list condition

 

2. Advertise-map을 활용하여 Policy 생성 (Center) 

 

이경우에는 advertise-map과 함께 어떤 map을 추가로 써야하냐면, Non-exist-map을 사용해야만합니다. 

왜냐하면, 3.3.3.0/24의 Routing이 없어질 때, 광고를 해줘야하기때문입니다. 

 

router bgp 555

 neighbor [Peer-IP] advertise-map DR non-exist-map condition

 

현재 CenterA와 CenterB 모두 6.6.6.6/32에 대한 라우팅이 없기때문에 advertise-routes정보는 확인 안하겠습니다. 

 

3. 내부 Routing 조정 

 

Center의 CE라우터에서 ISP로 특정 라우팅을 광고해주기위해서는 본인이 해당하는 라우팅을 가지고 있어야합니다.

다만 평시에는 Center에서 해당 대역을 ISP향으로 광고하지않아야하며,

Traffic flow를 종량제 회선을 거치지 않는 구성을 만들어야합니다.

 

제가 생각했을때 가장 복잡한 설정입니다. 

CE라우터들의 Serverfarm 간에는 기 활성화되어있는 EIGRP를 사용할 예정입니다. 

종량제 회선에 Delay를 왕창줘서 Default routing에 대해  종량제 회선을 경유하지않도록 말이죠. 

 

일단 Serverfarm L3인터페이스 설정을 하고, EIGRP에 네트워크 선언을 해주면 됩니다. 

<ServerfarmA>

int e0/2 

 no switchport 

 ip address 192.168.200.1 255.255.255.0

 delay 1000000

 

router eigrp 555

 network 192.168.200.0 0.0.0.255

 

<ServerfarmB>

int e0/2

 no switchport 

 ip address 192.168.200.2 255.255.255.0

 delay 1000000

 

router eigrp 555

 network 192.168.200.0 0.0.0.255

 

 

*일부 상황에서 특정 Public 서비스가 특정 Public서비스와 통신이 필요한 경우도 물론 있을것을 고려하여,

상호 호출이 되는 상황이라면, 내부로 서비스의 CIDR이 흘러들어가도록 기 설정한 ACL을 일부 손보면 될것 같습니다.

(수정)**이 방법은 인터넷 상황에서는 사용하긴 어렵습니다

 

 

AS-IS	TO-BE
ip access-list standard 1	ip access-list standard 1
permit 0.0.0.0	permit host 6.6.6.6
	permit 0.0.0.0
route-map default permit 10	route-map default permit 10
match ip address 1	match ip address 1

(수정)**이 방법은 인터넷 상황에서는 사용하긴 어렵습니다

 

 

동일한 Prefix를 전달받는 상황에서라면 우선순위를 지정하는것은 정말 많은 방법을 사용할 수 있기때문에, 

이번 시나리오에서는 Public service가 상호 호출을 하지않는다는 가정하에 ACL수정은 하지않았습니다. 

 

그럼 설정을 모두 마쳤고 client에서 Trace 및 Pingtest를 진행해보겠습니다. 

 

 

Trace에서 마지막 Destination port unreachable은 무시해주시고, 

정상적으로 Ping이 가능하고, 이 경우의 traffic flow를 확인할 수 있습니다. 

그럼 이 상황에서 CenterA의 라우팅 테이블과 advertise-routes정보를 한번 보겠습니다. 

 

너무 길어서 좀 잘랐는데, Routing table에는 3.3.3.0/24에 대한 라우팅이 존재하고 있으며, 

이에 따라 advertised-routes에는 6.6.6.6/32가 포함되지않고 있습니다. 

 

그럼 이제 DR 상황을 가정해서 Site router에서 회선을 죽여보겠습니다. 

 

 

CenterA에서의 라우팅 테이블과 Peer인 1.1.1.1로 광고하는 대역 정보입니다. 

제가 타이트하게 광고하는 대역을 나누지않아가지고, Site의 LAN대역이 DR 전후 모두 광고되고있는데, 

이마저도 advertise-map의 Route-map에 포함하면 큰 문제는 되지않으니 넘어가죠. 

 

중요한것은 3.3.3.0/24 대역에 대한 라우팅이 없어지면서, 6.6.6.6/32를 광고하기 시작한것이죠. 

CenterB에서도 한번 보겠습니다. 

 

 

CenterA와 동일하게 3.3.3.0/24에 대한 라우팅이 없어졌고, 6.6.6.6을 광고하기 시작했습니다. 

 

Client에서 Ping과 Trace의 결과를 한번 보겠습니다. 

 

제가 CenterA와 CenterB에서의 Inbound control을 안해서 위에 보이는것처럼 CenterB로 인입하는데 크게 상관은 없습니다. 

그리고 ServerfarmA에서 ServerfarmB를 거쳐서 정상적으로 통신하는 모습입니다. 완성이죠.

 

이게 실습환경에서는 저렇게 초라하게 라우터 1대로 장애 상황을 가정하고 serverfarm을 L3 하나로 해놔서 그렇지,

센터 단위에서의 DR 상황에서도 써먹을 수 있는 방법이라고 저는 생각합니다.

종량제 회선을 사용한다면 평소의 비용도 절감할 수 있구요.  

 

유의하실 점은 non-exist-map을 사용했을때는 permit route-map을 사용했다고 가정했을때,

match되는 ACL 혹은 Prefix-list에 있는 대역들이 전부 없어야지만 조건부 광고 대역이 광고되기 시작합니다. 

 

그럼 반대로 exist-map을 사용했을때는 ACL 혹은 Prefix-list에 있는 대역들중 하나도 없으면 광고되지않고,

하나라도 있을때 조건부 광고 대역이 Peer로 광고된다고 보면 됩니다. 

 

제가 설명하기로는 match ip address 혹은 match ip address prefix-list 등과 같이 라우팅 테이블에 있는 내용만 본다고 오해하실수도 있는데, as-path access-list를 추가하여, 해당 prefix의 as-path가 as-path access-list를 만족하는지,

안하는지로도 조건을 걸 수 있습니다. 

 

 

포스팅을 하는 와중에 exist-map을 활용한 조건부 광고의 쓰임새를 한번 생각해봤는 생각이 잘 안났습니다.

그나마 생각난 예를 한번 들어보겠습니다. 

 

인터넷 회선을 이중화해서 사용하고 있고, A라는 회선이 정말 좋은데, 가끔 ISP 내부에서 Local-as를 설정한 라우터를 경유해서 올 경우,

품질이 너무 않좋은 상황입니다. 

품질을 비교했을때, 좋을때의 A > 평시 B > 안좋을때의 A 인 셈이죠. 

원래 ISP의 AS는 100이라고 가정했을때, 100이 Next-hop인 routing일때만 specific한 라우팅을 전파하고,

그렇지않으면 B와 Prefix length는 같지만 품질이 않좋게 Prefix를 전파하는 상황을 가정해봤습니다.

한마디로 AS-PATH의 조건에 따른 인터넷 Inbound control을 생각해봤습니다 .

 

사실 용도가 많지는 않을것같다는 생각입니다. 

 

그럼 마무리로 실습때 작성한 advertise-map에 as-prepend까지 추가해서, 조건부 광고에 set설정도 가능한지 보겠습니다. 

CenterA에서만 적용해보겠습니다 .

 

route-map DR permit 10

match ip address prefix-list DR

set as-path prepend 555 555 555 <-추가

 

저는 아직까지 route-map에 설정한 as-prepend를 해당 라우터에서 보는법을 찾지못해서, 

설정 후에 Peer인 ISP1에서 확인해보겠습니다. 

 

 

맺으며

BGP가 너무 길다고 생각되실 수도 있는데, 아직 많이 남았습니다. 

그럼 다음에는 Peer로부터 광고받을 대역을 선별해서 보내게하는 설정을 해보겠습니다.