[#3-9]BGP template 이론편

BGP는 어느 라우팅 프로토콜보다 정책적인 측면이 강하다는 것은

여태까지 설명했던 여러 내용을 바탕으로 이해하셨을 것이라 이해합니다. 

 

그렇다면 '정책이 필요할만큼 큰 규모의 네트워크에서 많이 사용한다'라고도  이해할 수 있을 것입니다. 

 

아마도 peer-group을 통해서 일부 Neighbor에 일괄적인 정책을 설정하는것은 많이 해보셨을겁니다.

이것만으로도 BGP section 내에 많은 config가 줄고, 가독성이 좋아졌을거라고 생각합니다. 

단지 Peer-group만으로는 일부 기능을 제공하기 어려워 만들어진 template(session, Policy)기능이 있고,

적재적소에 사용한다면, 더욱 가독성있고 유연한 BGP configuration이 가능하지않을까싶어 소개를 하고자 합니다. 

 

그럼 시작하겠습니다. 

 

1. Peer-group의 정의 및 한계  

 

정의를 살펴보자면 동일한 정책을 공유하는 BGP neighbor을 그룹화 할 수 있는것이 Peer-group입니다. 

장점으로는 단순화된 구성과 효율적인 업데이트가 가능한데, 이는 업데이트에 생성에 필요한 시스템 리소스(CPU & Memory)의 양을 줄이는 부가적인 효과도 가져올 수 있습니다. 

 

동일한 Peer-group이라면 default-originate 등 Peer 기준으로 처리되는 Config를 제외하고, 동일한 정책을 공유합니다. 

그리고 iBGP와 eBGP는 별도의 Peer-group을 분리해야한 합니다. 

 

RR에서 Client에 동일한 정책을 묶거나 Full-mesh 환경의 iBGP에서 연결된 Peer에 똑같은 정책을 적용한다 했을때, 

효과적인 설정 방법이라고 생각합니다. 

 

그렇지만 이런 일관된 정책을 가져가는것에도 한계가 있습니다. 

 

이 경우를 생각해보시죠. 

 

우리는 인터넷 서비스 제공자 즉, ISP이고 PE에서 다수의 Customer와 BGP를 연동해야하는 상황이죠. 

물론 PE도 P나 RR과 iBGP를 연결해야하는 상황이라면 Peer-group을 통한 Config가 효율적이지만, 

PE와 CE간 은 어떨까요? 

 

CE가 가지고 있는 ASN도 모두 다를뿐더러, CE측에서 Password  설정과 같은 인증 Config 등 customizie가 필요한 상황이라면,

Peer-group을 통해 해결이 가능할까요? 

 

아니죠.

 

Peer-group은 연결된 모든 Peer에 같이 적용되는 설정이라, 적용하는 순간 Peer-group에 속한 모든 Peer 설정이 바뀌면서,

심각한 서비스 다운이 발생할 겁니다.

 

2. Peer-template 

 

Peer-template 은 위와 같이 Peer-group으로는 해결하지 못하는 상황에서 사용하기 위한 한가지 방법이며,

저는 개인적으로는 '확장판'이라고 생각합니다. 

* ACL과 Prefix-list같은 관계라고 생각하면 이해하기 편하실 겁니다. 

 

그 이유는 아래 그림을 보면서 설명하겠습니다. 

 

 

Template에는 상속(Inherit)의 개념이 적용됩니다. 

위 그림상 'iBGP 공통 Config'와 'eBGP 공통 Config'는 '공통 BGP config'를 상속하고 있습니다. 

그렇다면 'iBGP 개별 Config' 로 만들어 놓은 Template이 'iBGP 공통 Config'를 상속받는다면,

'공통 BGP config'까지 적용되는겁니다. 

*제가 굉장히 간단하게 도식화해서 그려놓았지만 실제 현장에서는 더 세분화해서 적용해놓을겁니다. 

 

만약 사전에 정의해놓은 config를 다른 값으로 변경해야하는 상황이라면, 개별 Config를 적용하는 Template에 특정값을 기입하여, 

상속받은 내용을 Overwrite할 수 있기때문에, '공통 BGP Config' template의 내용은 수정할 필요가 없습니다. 

 

예를 들어, 'iBGP 공통 Config'에 timer값을 60 180으로 설정해두었는데,

특정 iBGP peer는 timer값을 줄여 조금 더 민감한 Network 환경을 구성하고 싶다고 가정했을때, 

'iBGP 공통 Config' template의 timer값은 60 180일지라도, 'iBGP 개별 Config'에서 timer의 값을 5 15로 변경한다면 반영되는것이죠. 

 

따라서 자주 쓰는 설정들을 모두 반영한 공통 Template을 적용해놓고, Customize한 개별 Template을 설정한다면,

유연하게 peer에 대한 설정을 변경하여 적용할 수 있는것이죠. (ISP 혹은 MPLS 사업자에 최적화된게 아닐까 싶습니다)

 

 

*미리 설명을 드렸어야 했는데 이제야 언급을 하네요.

Template은 2 종류로 나뉘어집니다. 

 

-. session-template

-. policy-template

 

각 항목별 지원 가능한 Command 목록은 아래와 같습니다. 

 

Session Template	Policy Template
description	advertise-interval
disable-connected-check	allowas-in
ebgp-multihop	as-override
fallover	capability
local-as	default-originate
password	distribute-list
remote-as	dmzlink-bw
shutdown	filter-list
timer	maximum-prefix
translate-update	next-hop-self
transport	next-hop-unchanged
ttl-security	prefix-list
update-source	remove-private-as
version	route-map
	route-reflector-client
	send-community
	send-label
	soft-reconfiguration
	soo
	unsuppress-map
	weight

 

하나씩 살펴보겠습니다. 

 

* session-template

 

위에 도식화된 그림을 통해 설명했던 내용은 session-template에 대한 내용입니다. 

1개의 session-template내에는 1개의 session-template만 상속될 수 있으며,

몇 개까지 상속되는지는 장비 모델이나 OS version에 따라 다를 수 있어, 특정 갯수까지만 상속이 가능하다라고만 하겠습니다. 

 

우리가 흔히 쓰는 파일 시스템을 예로 들어보면, 상속을 따라가다가 나오는 마지막 Template이 Root라고치면,

하위로 하나씩 내려가면서 비어있는 파일은 추가, 이미 있던 파일은 Overwrite되는 방식이죠 .

 

상단에 예에선 '공통 BGP Config'가 'Root'가 되고, 하나씩 내려오는겁니다. (상속을 거슬러 조상님부터 적용하며, 현재로 내려오는 느낌)

 

* Policy-template 

 

용어 그대로 Policy(정책)에 대한 Template이고, 이는 session과 유사하지만 조금 다른 부분이 있습니다. 

상속이 가능한 부분은 유사하지만, 1개의 Policy-Template내에 여러개의 Policy-Template을 상속받을 수 있습니다. 

 

하나의 Policy-Template 내에 여러개의 Policy-template을 상속받을 때,

어떤 Policy-Template이 먼저 적용이 되고, 어떤 Policy-Template이 나중에 적용되어

기존의 내용을 Overwrite할지 순서가 정해져야만 합니다. 

이를 위하여, policy-template에서는 상속받는 policy-template에 Sequence가 붙습니다. 

1-65535 사이 값을 지정할 수 있으며, 낮은 값일수록 먼저 적용되고, 높은 번호일수록 뒤에 적용되어 사전에 설정된 내용을 Overwrite할 수 있습니다. 

 

아래와 같이 Policy-template의 그림을 한번 더 그려보았습니다. 

 

대략적으로 그려봤고, 제일 왼쪽에 있는 'BGP 개별 config' 또한 Policy-template입니다. 

 

이제 적용되는 순서를 한번 나열해 보겠습니다. 

 

1. Sequence가 1인 Template을 적용하려고 찾아감

 

2. Sequence가 1인 Template에서 상속받는 Template이 있어, 다시 찾아가고 Weight 32768을 적용 

 

3. 빠져나오면서 allowas-in 설정 추가 적용 

 

4. Sequence 2번, as-override 설정 추가 적용

 

5. Sequence 3번, Next-hop-self 설정 추가 적용

 

6. Sequence 4번, Weight 설정이 이미 32768 적용되어있었지만, Sequence 4번 Template으로 인해 weight 10으로 overwrite 

 

session-template과 마찬가지로, 몇개까지의 policy-template이 적용되는지는 장비 모델별, OS version별로 다를거기 때문에, 

사전에 벤더를 통하여 Capacity를 확인해보는것도 좋은 방법입니다. 

 

 

 

3. Peer-template의 단점 

 

단점은 당연히 있습니다. 

 

우선 동일한 Config를 설정해야하는 Peer가 지속적으로 추가되는 경우, Peer-group이 더 낫습니다.

동일한 Config인데 굳이 template을 활용하기 보다는 Peer-group으로 일관된 정책을 가져가는것이 훨씬 가독성있고 좋습니다.

 

예를 들면, RR과 RR-client 사이의 iBGP에서 Peer가 지속적으로 꾸준히 늘고 있는 상황이라 했을때, 

굳이 기존의 iBGP peer와 신규로 추가되는 Peer간 설정이 다를 필요가 없습니다. 

고로 template을 활용하면 오히려 가독성이 떨어질 수 있습니다. 

 

또한 정밀하게 policy/Session template을 설계하지않는 이상, 기존보다 가독성 및 활용성이 떨어질 수 있습니다. 

Session에서는 수직적 구조를, Policy에서는 수직/수평적 구조를 제대로 설계해야만,

추후 신규 Peer 연결 시, 소요되는 Effort를 줄일 수 있다고 생각합니다. 

 

그리고 간단하게 해본 결과, Peer-group과 template은 같이 쓸 수 없었습니다. 

두개를 같이쓴다면 더욱 간결하게 Config를 짤 수 있을것 같았는데, Peer-group에는 Template을 적용할 수 없었습니다. 

 

 

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

 

맺으며. 

Template이 복잡하면 복잡할 수록 가독성이 떨어지는건 당연해지는지라, 

BGP 내부의 Config을 입력받아, 각 Peer에 설정된 내용을 가독성있게 풀어주고,

어떤 Template이 어떻게 상속되고있는지 설명해주는 프로그램이 있으면 편하겠다 생각했습니다. 

 

이에 한번 틈틈히 만들어 보고 괜찮은게 나오면 공유하도록 하겠습니다. 

 

Template에 대한 LAB은 다음번 포스팅에 진행하도록 하겠습니다 !