BGP 딥 다이브(BGP config, split-horizon, Router Reflector, next-hop self, BGP confederation, local-preference, med)

라우팅 프로토콜 계통도

BGP

AS(Autonomous System : 네트워크 관리자에 의해 관리되는 라우터 집단)를 한 단위로 AS들 간을 연결해주는 라우팅 프로토콜이 바로 Border Gateway Protocol BGP

AS(Autonomous System)?

조금 더 자세하게 적어보겠습니다. 대충 짚고 넘어갈만한 얘긴 아니라서,,,아무튼 위에서 말했듯이 동일한 라우팅 정책으로 하나의 관리자에 의하여 운영되는 네트워크 집단으로 한 회사나 단체에서 관리하는 라우터 집단을 자율 시스템(Autonomous System) 라고 하며, 각각의 자율 시스템을 식별하기 위한 이너넷 상의 고유한 숫자를 망식별 번호 AS번호 라고 합니다. 방대해진 네트워크 크기로 인해 라우팅 정보도 같이 방대해졌고 전체 네트워크를 하나의 프로토콜로 관리하기 어려워졌습니다. 따라서 이를 계층화하고 단위 별로 라우팅을 효율적으로 관리하기 위해 AS가 도입됐습니다.

EGP VS IGP

IGP는 위의 사진처럼 네트워크 집합을 나눴을 경우 그 집합 안에서의 라우팅 프로토콜을 말하는데 OSPF,EIGRP 등이 이에 속합니다. 이러한 프로토콜을 이용하여 각기 다른 AS들을 연결해주면 네트워크 및 장비 부하 현상과 대역폭 고갈이라는 문제가 발생할 수 있기에 IGP를 이용하는 AS간의 통신이 좋지 않습니다. 따라서 이들끼리 통신하기 위해 사용하는 것이 EGP이고 현재는 EGP 중 BGP만을 이용해 통신하고 있습니다.

	IGP	EGP
Neighbor 결정	자동 탐색	수동 설정 필요
Convergence 수렴성	빠름	안전성 위주로써 둔감
라우팅 범위	AS의 내부 라우터 간	상호 AS 간 (IGP 용으로 설정도 가능)
라우팅 방식	distance-vector, link-state	path vector
프로토콜	eigrp,rip,ospf,static,	BGP

특징

1. IGP보다 컨버젼스(정보의 수렴, 종합, 업데이트) 속도가 느리지만, 대용량의 라우터 정보를 교환할 수 있음
2. HELLO 메세지가 아닌 TCP 179을 이용하여 NEIGHBOR를 맺음
   1. IGP와는 다르게 인접 라우터가 아닌 라우터와도 NEIGHBOR 형성이 가능하지만 자동으로 감지하지 못하기 때문에 수동으로 NEIGHBOR 설정을 해주어야 함
   2. 형성 이후엔 60초마다 KEEPALIVE 교환하여 NEIGHBOR의 상태를 확인함
3. PATH VECTOR
   1. 하이브리드 라우팅 방식을 사용하는데, 거리-벡터 방식과링크-스테이트 방식을 혼횽해서 사용함
   2. 최적 경로를 위해서는 거리 백터 방식을 이용하지만, 상호 감시, 업데이트에는 링크 스테이트 방식을 이용함
   3. BGP는 문제가 생기면 여러 네트워크 집합의 영향을 주기 때문에 조금 더 느리지만 안정적인 거리 벡터 방식과 빠르고 루프 현상이 발생하지 않는 링크 스테이트 방식을 모두 사용하는 것임
4. AS는 약 65000개가 사용되고 있으며 IANA에서 관리함
   1. 번호 부여 범위 1~65535
   2. 64512~65543 는 사설 대역
   3. 65535는 예비용

용어

용어	내용
eBGP	AS와 AS 간의 라우팅 정보를 교환하기 위해 사용하며 두 AS간의 구간을 eBGP 또는 DMZ 구간이라고 함
iBGP	AS 내부에서 BGP 라우팅 정보를 교환하기 위해 사용
IGP	내부 라우팅 프로토콜, 같은 AS 내부에서 사용함

구성하면서 주의할 점

Split-horizon 문제점과 해결

split-horizon은 라우팅 루핑을 막기 위한 기술이지만 한번 라우팅 광고를 했던 경로로는 다시 라우팅 경로를 하지않는 기법으로 BGP 구성에서는 조금 다른 개념으로 작동하는 것 같습니다. 따라서 iBGP 구성에서 문제가 될 수 있습니다. 아래의 사진을 예시로 들어보겠습니다.

AS30의 R1은 AS 20의 R5에게 통신하고 싶어 AS 10인 R2를 상대로 경로를 광고합니다.

하지만 R3의 iBGP에서는 이 내용을 광고하지 않습니다. 왜냐? 바로 BGP split-horizon 때문입니다. 같은 AS의 iBGP에서 온 라우팅 정보이기 때문에 루핑 방지를 위한 split-horizon 룰에 의해서 다시 광고하지 않는 것 입니다. 따라서 R3 라우터는 모든 네트워크의 정보를 알고 있지만 같은 iBGP에게 이 정보를 다시 광고하지 않고 R5는 영원히 R1을 모르며 R1원도 영원히 R5를 모르게 되는 것입니다.

2가지 방법으로 이에 대한 문제를 해결하고 통신을 정상화 할 수 있는 방법이 있습니다.

Split-horizon : full mesh

full mesh : 라우터를 모두 서로 상호연결하는 full mesh 토폴로지로 구성하여 연결된 라우터 간에서 각각 Neighbor 협상 하도록 함으로써 split-horizon을 우회할 수 있습니다. 이런 방법은 규모가 커질수록 관리하기 힘들어지고 피어의 수가 감당할 수 없는 수준으로 커져 추천하지 않습니다.

ex) 필요한 피어의 수 : n(n-1)/2

Split-horizon : Router Reflector(RR)

특정 router를 route reflector로 지정하여 router reflector client에 한하여 split-horizon 룰을 면제받을 수 있습니다. 이 설정을 해보기 전에 몇 가지 단어의 뜻을 알고가면 좋을 것 같습니다.

Router reflector : split-horizon 규제를 면제받은 라우터

Router reflector client: 클라이언트로 지정된 라우터

non-client : router-reflector와 neighbor지만 클라이언트가 아닌 라우터

cluster : 클라이언트와 RR의 집합

cluster-id : RR의 라우터 ID가 cluster id로 사용된다.

cluster list : 특정 경로가 현재 router 까지 통과해온 cluster들의 id list. 이 정보를 통해서 만약 외부에서 받은 라우팅 정보에 자신이 속해있는 cluster ID가 있다면 routing loop가 발생한 것으로 간주 하고 이 정보를 무시한다. RR의 루프 방지 기술 중 하나입니다.

originator ID : 현재의 AS에서 특정 경로를 BGP에 포함시킨 라우터의 라우터 ID, 광고 받은 특정 경로의 originator ID가 자기 자신이면 이 정보를 무시한다. 즉 RR의 루프 방지 기술입니다.

1. eBGP neighbor에게서 수신한 정보는 모든 client와 non client 모두에게 전송

2. Non client에게서 수신한 정보는 모든 client에게 전송한다. 하지만 다른 non client에게는 전송하지 못함

3. Client에게서 수시한 정본느 모든 client와 non client에게 전송함

위 세 절차를 통해서 RR이 작동하고 라우팅 테이블을 공유합니다.

#RR 라우터
rotuer bgp [as]
neighbor [addresses] route-reflector-client

bgp cluster-id [addresses]
#다수의 라우터와 클라이언트를 하나의 bgp cluster로 지정하고 싶을때 사용하는 명령어

Next Hop problem

위 사진을 예시로 들면서 설명하겠습니다. 나중에 설정하면서 알겠지만 eBGP 구간을 DMZ라고 부르는 이유는 BGP 구성에서 이 둘에 대한 라우팅 경로를 따로 알리지 않는다는 것입니다. 두 라우터는 서로 로컬 연결이 돼있기 때문에 통신에 문제가 없습니다. 아무튼 본론으로 돌아와서 이럴땐 전혀 문제가 없지만 조금 멀리 있는 iBGP나 eBGP를 생각해볼 필요가 있습니다.

위와 같은 상황이 생기게 됩니다. 우리는 eBGP구간 즉 DMZ 구간을 라우팅 테이블에 추가시키지 않기 때문에 eBGP라우터 외의 라우터들은 eBGP 구간의 정보를 받아올 수가 없는 것입니다. 따라서 이를 해결하기 위한 방법이 있습니다.

Next Hop solution eBGP 구간을 IGP에 포함

즉 AS와 AS의 연결 구간인 DMZ를 OSPF 같은 IGP에 등록시켜 직접 알려주는 방법으로 많이 사용하지는 않는 것 같습니다.

Next Hop solution next-hop-self 사용

경계 라우터(eBGP 구간)에 next-hop-sef를 설정하여 next-hop 정보를 자신으로 변경하여 광고하는 설정으로 가장 일반적으로 사용되는 방식입니다.

사진을 통해 보시면 알겠지만 R2가 R1의 경로를 자신의 경로인 것 처럼 광고하여 R3에게 알리는 방식입니다.

#eBGP 라우터에 설정
router bgp [AS]
neighbor [addresses] remote-as [as num]
#iBGP 설정
neighbor [addresses] next-hop-self 

위 설정을 통해 R1으로 부터 오는 주소가 사실상 R2에서 오는 것으로 보이게 하여 주소를 알리는 방법입니다.

동기화 법칙의 문제점과 해결

여기서 동기화란 BGP로 연결된 다른 AS의 라우팅 정보를 IGP에서도 학습해야지 통신할 수 있다는 얘기입니다. (iBGP의 내용을 학습한다는 뜻입니다.)

이러한 동기화가 왜 문제가 될까요? AS내의 모든 라우터가 BGP 설정이 이루어져 있다면 문제가 없지만 중간에 BGP설정이 존재하지 않는 라우터가 존재할 시 블랙홀 현상이 발생할 수 있습니다.

R4가 AS20의 정보를 R2에게 넘긴다고 생각해봅시다. 사실상 R2에게 알리지만 R3회선을 사용할 수 밖에 없습니다. 하지만 이 상황에서는 R3는 iBGP라우터가 아니기 때문에 라우팅 테이블을 R2에게 포워딩만 하고 학습하지 않습니다. R2는 전달 받은 라우팅 테이블을 정상적으로 가지게 되고 학습합니다.

이제 R2는 가지고 있는 라우팅 정보를 바탕으로 AS 20에 통신하려고 하지만 R3에서는 그 경로를 모릅니다 !!!!!!! 따라서 그 패킷을 드랍하게 되고 블랙홀이 되는 것입니다.!!!!!!!!!!!!!!!!!!! 이러한 문제를 해결하기 위해 3가지 해결법이 존재합니다.

동기화 해결 : no sync

요즘 나오는 ios들에서는 기본적으로 설정되어 있습니다. 동기화하지 않겠다는 뜻으로 동기화 법칙을 무시함으로써 이러한 문제 자체를 없애는 것입니다. 당연히 동기화하지 않기 때문에 모든 라우터에서 블랙홀 현상이 없어집니다.

동기화 해결 : BGP를 IGP에서 재분배

IGP에서 BGP정보를 재분배 해줌으로써 IGP가 BGP정보를 알게 되고 iBGP와 IGP간 동기화를 이룰 수있습니다.

router bgp []
red eigrp []
red ospf []

router eigrp []
red bgp [] metric 100 1 1500

router ospf []
red bgp []

동기화 해결 : confederation

위 방법은 하나의 AS에서 서브 AS를 생성하여 분할 설정하는 방법이다. 위 설정을 통해 라우터들은 서로 다른 서브 AS를 갖게 됨으로써 iBGP로 통신하는 것이 아닌 각각의 개별적인 eBGP로 통신하게 되는 것이다. 따라서 eBGP를 통해 라우팅 정보를 주고 받기 때문에 동기화 문제가 해결된다.

confederation을 적용하면 eBGP의 협상처럼 작동하기 때문에 기존 동기 법칙이 적용되지 않아 문제를 피할 수 있다. 또한 eBGP처럼 이용하기 때문에 eBGP의 라우팅 정책도 이용할 수 있다.

타 AS로 나갈때는 sub-as의 번호가 모두 제거되어 confederation이 되어 있는지 알 수 없다.

일반 ebgp와의 차이점 :

1. sub-as 간에서 med, next-hop, local preference이 동일한 값을 가지고 변경되지 않는다
2. aconfederation 내부에 추가되는 as 번호는 경로결정에 사용되지 않고 루프 방지용으로만 사용된다

router bgp [sub-as]
#그냥 as 번호가 아닌 서브 as 번호로 bgp table 구성
bgp confederation identifier [as] 
#서브 as를 사용하기 때문에 원래 AS 선언
bgp confederation peers [n]
#자신의 peer인 라우터 서브 AS를 설정
neighbor [addresses] remote-as [sub-as]
#sub-as를 이용하는 라우터에 연결된 네트워크에 대한 라우팅 테이블 구성
neighbor [addresses] ebgp-multihop [n]
#eBGP 라우터가 로컬로 연결되어 있지 않을때 하는 설정 
#기본 ttl이 1인 eBGP의 ttl을 차이나는 홉 수만큼 늘려서 neighbor 형성이 되도록 만듦

BGP 테이블 기호 의미

Codes	의미
s	경로 요약 (Suppressed), 지정된 경로가 억제됨
d	경로가 up/down을 반복하여 네트워크가 불안정 되는 상태를 막기 위해 자주 반복하는 곳의 경로가 차단됨 (Damped)
*	경로가 유효함 (Valid)
>	최적의 BGP 경로임 (Best), 라우팅 테이블에 등록됨
i	iBGP로 배운 경로 정보
r	BGP 최적 경로이기는 하나, IGP 보다 AD 값이 높아서 라우팅 테이블에는 BGP 경로로 업데이트되지 못함[출처] BGP란? (Boarder Gateway Protocol)|작성자 불곰

BGP 경로 선택 우선순위 요약

우선순위	지표
1	WEIGHT
2	local preference
3	AS_Path
4	originate route
5	MED
6	eBGP
7	iBGP

BGP configuration

AS-100.2 (IGP라우터)

router eigrp 100
network 192.168.20.0 0.0.0.255
network 210.110.40.0 0.0.0.255

AS-100.1 (BGP 라우터)

router bgp 100
neighbor 210.110.30.1 remote-as 200
#eBGP 지정

network 210.110.40.0 mask 255.255.255.0
#내가 가진 네트워크 알려주기 
#주의할 점 같은 AS의 네트워크를 알려주는 거임
#DMZ 구간의 network는 광고하지 않음!!!

red eigrp 100 
#위 글에서의 동기화 법칙 해결을 위한 재분배

router eigrp 100
network 210.110.40.0 0.0.0.255
red bgp 100 metric 100 1 255 1 1500
#eigrp 재분배에서는 metric값을 알려주지 않으면 안됨! 중요

sh ip bgp summary 
#명령어로 eBGP 성립 확인

AS-200.1 (BGP 라우터)

router bgp 200
neighbor 210.110.30.2 remote-as 100
#eBGP지정

network 210.110.20.0 mask 255.255.255.0
#내가 가진 network 알려주기
#주의할 점 같은 AS의 네트워크를 알려주는 거임
#DMZ 구간의 network는 광고하지 않음!!!

red ospf 1
#위 글에서의 동기화 법칙 해결을 위한 재분배

router ospf 1
network 210.110.20.0 0.0.0.255 area 0
red bgp 200 subnets
#위 글에서의 동기화 법칙 해결을 위한 재분배

AS-200.2,3 (IGP 라우터)

router ospf 1
network [자신들의 네트웤]

결과

AS-200.3 라우터에서 확인하면 외부 AS eBGP의 경로까지 모두 학습한 것을 확인할 수 있다. 라우팅 테이블의 E2는 재분배를 통한 학습을 뜻하며 재분배가 정상적으로 이루어졌다는 것을 확인할 수 있다. 또한 eigrp 테이블에서도 EX 메세지를 통해 재분배가 성공한 것을 볼 수 있다.

AS 100에서 200의 라우터로 ssh가 성공하는 것을 볼 수 있다.

BGP 심화 설정

BGP local preference

local preference를 이용하여 end point를 직접 선택할 수 있습니다. 가중치가 더 높은 곳을 기본 경로 즉 end point로 사용하게 되기 때문에 기본값인 100보다 높게 설정하여 하나의 특정 경로를 지정해줄 수 있습니다. local preference를 사용하게 되면 모든 패킷이 그 가중치가 가장 높은 경로로 향하게 됩니다.

위 같은 BGP 토폴로지에서 Router3(1)(3)에서 Router3(1)로 가는 경로로 패킷을 보내고 싶을땐 이렇게 설정합니다.

Router3(1)(3)# route bgp [n]
Router3(1)(3)# bgp default local-prference 200 

또는 

Router3(1)(3)# route-map [name]
Router3(1)(3)# set local-preference [n]
Router3(1)(3)# route bgp [n]
Router3(1)(3)# neigbor [address] route-map [name] in

BGP aggregation

다수의 BGP테이블의 내용을 축약하여 BGP neighbor에게 광고하는 기법

router bgp [n]
aggregate-address [address] [netmask]

 

BGP MED(Multi-Exit Discriminator)

MED는 인접 AS에게 라우팅 업데이트시 라우팅 결정에 영향을 미쳐서, 로컬 AS로 입력되는 트래픽의 방향을 결정할때 사용하는 속성입니다. MED값은 0부터 4294967295까지 있으며 0이 기본 값이다.

원래의 MED값은 eBGP에게 전송되지 않지만 임의로 정해준 MED값은 전송된다. 따라서 서로 다른 neighbor에게서 동일한 BGP 정보를 수신할때 MED값이 더 작은 경로를 최적 경로로 선출하게 된다.

configuration

route-map [name]
set metric [num]
router bgp [as]
neighbor [addresses] route-map [name] in/out
#in: 트래픽이 들어올때 적용
#out: 트래픽이 나갈때 적용