[#3-11]BGP range neighbor 활용

이번 시간에는 BGP의 또 다른 기능인 range neighbor 기능을 확인해보겠습니다. 

 

BGP range를 적용할 때, config 자체는 아래처럼 간단합니다. 

여러 정책을 설정하면서 가독성에 문제가 생기지만요. 

 

1. Peer group 생성 

2. 특정 CIDR을 생성한 Peer group과 Mapping 

3. Peer group에 정책 Mapping 

 

실제 Configuration은 아래와 같습니다. 

 

 

router bgp [ASN]

 neighbor A peer-group                                       # 사전에 'A' 라는 Peer-group을 생성 

 bgp listen range A.B.C.D/nn peer-group A       # Neighbor의 IP range를 정의하고 Peer-group 'A'에 Mapping 

 neighbor A [remote-as ASN | local-as ASN | timer etc.. ]  # 각종 정책을 Peer-group에 매핑

 

이전 포스팅에서 설명한 바와 같이, Template은 Peer-group에 적용하지 못하지만

Peer-group 그자체로 Config의 간소화가 가능하며, Range를 활용했을때는 더욱 간소화해집니다. (단점은 뒤에 말하겠습니다)

 

그럼 어떨때 유용한지를 알아보기 위해 한번 상황을 가정해보겠습니다. 

 

우리는 MPLS를 제공하는 ISP의 네트워크 엔지니어라고 말이죠. 

 

보통 MPLS 환경에서는 iBGP를 사용하면서 source-address를 loopback으로 지정하고,

그 loopback에 대한 경로를 확인하고자, OSPF와 같은 IGP를 함께 사용합니다. 

Underlay에서는 OSPF, 그로부터 받은 Routing을 활용하여, MPLS를 위한 iBGP를 구현한다 라고 생각하면 되겠네요. 

 

iBGP같은 경우에는 기본적으로 iBGP로부터 받은 Prefix를 다른 iBGP neighbor로 전달하지 않습니다.

  *Spilt-horizon 방지 

  **allowas-in 같은 경우는 eBGP로부터 받은 Prefix에 자신의 AS가 몇개 포함되어있더라도 수용한다이니, 본 예시와는 무관합니다. 

 

그렇기에 iBGP에서는 Full-mesh가 기본 구성이나, 한 지역에서도 거의 불가능한 Full-mesh를 여러 나라에 PoP이 있는 MPLS 사업자가 구성하는데는 현실적으로 무리가 있습니다. 

아시다시피 이런 문제를 해결하기 위하여, 우리는 RR(Route-reflector)를 사용합니다. 

 

그렇다면 특수한 경우를 제외하고, RR 입장에서 neighbor는 2가지 type이 있습니다. 

 

1. 다중화된 RR과 맺는 iBGP

2. route-reflector-client와 맺는 iBGP

 

제가 ISP에서 근무하는 엔지니어가 아니다보니, RR을 몇중화할지 감이 잡히지않아 구체적인 Peer수는 생략하겠습니다만, 아마도 10개는 안되지않을까 싶습니다. 

이때는 peer-group을 써도 그만, 안써도 그만이라고 생각하지만, RR-clinet는 어떨까요?

 

예상컨데 RR-client는 RR의 수와는 다르게  정말 많을겁니다. 

세상에는 정말 많은 PoP이 있고 그 안에 P, PE 적어도 2개 이상은 있으니까요.  

 

이런 상황에서 BGP range를 사용하지않고, 보통 Peer-group를 사용했을때는 아래와 같이 Config될겁니다.

 

 

예시1) Range neighbor를 사용하지 않은 경우 

===============================================

router bgp 1

 neighbor RR-client peer-group

 neighbor RR-client remote-as 2

 neighbor RR-client description Route-reflector client 

 neighbor RR-client route-reflector-client 

 neighbor RR-client timer 5 15

 neighbor 192.168.0.1 peer-group RR-client

 neighbor 192.168.0.2 peer-group RR-client

 neighbor 192.168.0.3 peer-group RR-client

                                  .

                                  .  (생략)

                                  .

 neighbor 192.168.0.254 peer-group RR-client

 address-family vpnv4

  neighbor 192.168.0.1 activate  

  neighbor 192.168.0.2 activate  

  neighbor 192.168.0.3 activate  

                                  .

                                  .  (생략)

                                  .

 neighbor 192.168.0.254 activate

===============================================

 

위의 경우에서는 Range neighbor를 사용하지않았을때, 254개의 RR-client가 연결될때의 예상 Config입니다. 

각 neighbor를 address-family에서 개별로 activate시켜야 하므로,

Peer-group에 정책을 적용하는것 외에 254 * 2의 command line이 필요합니다. 

 

그렇다면 Range neighbor를 활용한 Configuration 을 작성해보겠습니다. 

 

예시2) Range neighbor를 사용한 경우 

===============================================          

router bgp 1

 bgp listen range 192.168.0.0/24 peer-group RR-client

 neighbor RR-client peer-group

 neighbor RR-client remote-as 2

 neighbor RR-client description Route-reflector client 

 neighbor RR-client timer 5 15

 neighbor RR-client route-reflector-client 

 adress-family vpnv4 

  neighbor RR-client activate

===============================================

 

예시1과 2를 비교해봤을 때, 확실히 Range neighbor을 사용했을 때, command Line 수가 줄어든 모습입니다.

예시2의 Config에 대한 설명을 하자면,

192.168.0.0/24에서 BGP neighbor을 요청해서 연결되는 경우, 자동적으로 Peer-group이 매핑되고,
Peer-group에 적용된 Session과 Policy 가 적용되며, 자동으로 vpnv4에서 activate되는 구성입니다. 

 

 

아래는 제가 실습을 한 내용입니다.

200.200.200.2에 대한 peer는 개별적으로 선언한 Peer이며, 

100.100.100.0/24는 Range로 선언된 상태입니다. 

 

'show tcp brief all'을 통해 현재 Router에 Open되어있는, 흔히 Listen중인 tcp port정보를 확인해보았습니다. 

 

State가 LISTEN인 부분을 보시죠.

Peer에 대해서 개별적으로 선언한 경우엔 자동적으로 Peer의 IP Address/Random port에서 Local의 179 port에 한해  오픈이 되어있는것을 볼 수 있습니다. 

 

Range neighbor 설정을 한다면 3번째 행과 같이 Foreign Address를 제한하지않는 상태(*.*)에서 179를 Listen하게 됩니다. 

 *위 캡쳐는 두개 다 설정된 상태라 다 보이는데, Range설정을 하지않는다면 3번째 행은 생성되지 않습니다. 

 

다만, 저렇게 Foreign Address가 *.*로 오픈되어있더라도 Range에 속하지않는 IP address에서 telnet을 연결해보면,

'connection refuse'가 떠버립니다. 아예 TCP 세션 오픈조차 연결되지않는것이죠. 

 

TCP 3 hand shaking 과정에서 '이건 BGP 연결을 위한 Session try다!'라고 명시해서 SYN 메세지에 어떤 값이 입력되어있어야 Session을 구성하는지, 아니면 저 Foreign Address 이외에도 별개의 Allow list가 있는지는 패킷을 떠보지않아서 정확하진 않지만, 

range로 정의한 IP CIDR내의 IP address에서는 Telnet을 해보면 정상적으로 오픈이 되는 것으로 보아, 

제 생각에는 'sh tcp brief all'에는 표기가 안되지만 별개의 Allow list가 있는지않을까 싶습니다. 

무분별한 Session 공격을 방지하기 위해서더라도 그게 맞는 동작같긴 합니다. 

 

다만 좀 더 가독성있게 Foreign Address에 LISTEN되고있는 CIDR을 적는게 더 좋지않나 하는 생각입니다. 

 

 

그리고, Range에 속한 Neighbor의 tranport connection-mode를 보면,

제가 별도의 설정을 하지않았어도 Passive mode로 오픈되어있는것을 볼 수 있습니다.

 

어찌보면 당연한것이, 언제 연결될지도 모르는 IP에 지속적으로 Connection try를 하는것은 적절치 않은 동작방식이기 때문입니다.  

 

 

 

다만 꼭 모든 상황에서 Range neighbor가 좋지는 않습니다. 

 

BGP Range neighbor의 장점보다 우선적으로 단점에 대해 기술해보겠습니다. 

 

아마 눈치채신분들도 있겠지만, Range로 지정했을때는 address-family내에 개별 Peer에 대한 Config가 불가합니다. 

 

예를 들면, 위에 제가 작성한 Config에서 192.168.0.2만 ipv4에서 activate를 하지말아야한다면 불가능합니다. 

일반적으로 Peer-group으로 그룹화를 할때보다 강한 그룹화가 되며, 개별 Peer에 대한 control을 못하게 됩니다. 

 

극단적으로 한 PE에서 문제가 생겨서 해당 PE에서 받아오는 Prefix들이 꼬였다고 가정해보겠습니다. 

BGP neighbor가 Flap되는 상황에서 Underlay에도 문제가 생겨서 직접 PE에 접속을 못하는 상황입니다. 

 

그때 RR에서라도 해당 PE에 대한 Neighborship을 끊기위해 neighbor shutdown을 해야하는데,

Range로 지정된 상태에선 이게 불가능하다는 겁니다. 

해당 PE로 향하는 모든 경로를 끊고나서야 해당 PE와 neighborship이 끊어질겁니다. 

 

no activate 혹은 shutdown 뿐만 아니라, 어떤 custormize간 command도 개별로는 적용 불가합니다.

 

위에 말한 내용과 비슷한 맥락인데, 일괄적인 정책이 적용되기에 Password의 개별화가 불가하므로, 

보안적인 측면에서 보안성이 떨어진다고 볼수도 있습니다. 

이뿐만이 아니라, Range자체를 Open하다보니, 만약 인가되지않은 장비가 BGP 연결시도를 했을때, 보안적으로 취약할 수 있습니다. 

내부망에서 사용할때는 문제가 없는것이 아니냐 할 수도 있겠지만, 물리 보안이 무력화된 상황이면서,

공통적으로 사용하는 Password가 탈취된 상황이라면 치명적인 Rogue 장비로 인해 전체 서비스 장애가 발생할 수 있습니다. 

 

 

이어서 장점을 살펴보겠습니다.  

 

Range를 사용하지 않았을때는 Peer-group 전체에 대한 Activate선언이 불가능합니다. 

반대로, Range를 사용할때는 Peer-group에 대한 일괄 Activate가 가능합니다. 

 

개별 Command적용이 불필요한 상황에서는 Session에 대한 설정과 Policy에 대한 설정 모두 통합적으로 적용이되기에,

Range를 활용했을 때 가독성을 향상시키며 불필요한  HW 자원 낭비 최소화를 할 수 있습니다. 

 

또한 P 혹은 PE가 늘어날때, Range를 적용한 상태라면, Range를 적용한 장비에서 별도의 추가 Config가 불필요합니다. 

단순히 P 혹은 PE쪽에서 알맞은 Config를 진행한다면, RR에서 별도 Config를 해줄필요가 없는것이죠.

 

그리고 제가 단점이라고 명시한 보안적인 측면도 어느정도 보완이 가능합니다. 

TCP base기반으로 BGP neighbor가 맺히기때문에, GRE over IPSec 혹은 IPIP over IPSec을 활용한다면,

Password를 활용한 BGP 자체적인 보안 설정은 그렇게 크게 문제되지않을까 생각됩니다. 

물론 GRE 등 터널링 프로토콜과 암호화를 함께 사용했을때에 한해서긴 합니다. 

 

RR의 구조에서 Underlay를 구성하는 IGP(OSPF or EIGRP 등)단에서 보안성을 가져가는 방법도 있다보니,

장점보다는 단점을 커버할 수도 있다 ~ 라는 측면으로 이해해주시면 감사하겠습니다. 

 

 

 

맺으며 . .

 

저는 range를 활용한 경우와 사용하지않을때의 Peer-group을 모두 사용해보았고, 어떤것이 무조건 더 좋다! 라고는 못하겠습니다. 

단지 주관을 말씀드리자면 적재적소에 알맞게 사용하자라는 입장입니다. 

 

매번 말했다시피 사용할 수 있는 기술 스펙트럼이 늘어난 상태에서, 여러 방면을 고려해서 선택하는것이 베스트입니다.