본문 바로가기

Network 모험기

[#3-5]BGP Community 활용하기

오늘은 BGP의 기능 중에서 Community를 설명해볼까 합니다. 

 

Community 자체는 BGP Best path 프로세스를 변경하지는 않지만, 

경로 집합을 표시하기 위해 커뮤니티를 플래그로 사용할 수 있습니다. 

즉, 쉽게 말해 Community는 일부 공통 속성을 공유하는 접두사 그룹입니다 

 

Community의 Field는 4개의 옥텟값으로 구성되어있고,

이에 따라 1 ~ 256*256*256*256(4,294,967,295)의 값을 가질 수 있습니다. 

 

위처럼 하나의 정수로는 제어하기 어려울 수 있으니, 아래 명령어로 새로운 format 형태로도 사용할 수 있습니다 

ip bgp-community new-format

 

'aa:nn' 앞에는 AS, 뒤에는 인덱스로 기재해서 쓰는것으로 보입니다 

 

예를 들어서, 받은 대역 중 community 값이 100인 대역을 선별해서 광고를 받지않는다던지, 100만 광고를 한다던지 할 수 있습니다. 

이건 뒤에 Lab을 할 때 자세히 살펴보기로하고, 그 외에 Community가 가진 기능을 소개하겠습니다. 

 

그럼 이제부터 Well-known community라고하는 아이들의 정의부터 하나씩 보도록 하겠습니다. 

 

1. gshut 

  Graceful shutdown을 하게되면, Peer에게 라우팅이 전달될 때, 해당 community값을 추가로 달고 나갑니다.
  LAB에서 한번 확인해 보겠습니다. 

  광고를 받는 대역에서는 gshut을 받게되면 특정 액션을 취하도록 route-policy를 걸 수도 있죠 
  본 포스팅에서는 Graceful shutdown까지만 소개하고, route-policy는 별개로 다루겠습니다
   
2. internet

  이 community를 달고 들어오는 대역이 있다면, 모든 BGP peer에게 광고하라고 하는 내용입니다.

  내가 보낸 community로 Peer의 동작을 강요할 수 있다는 점이 신기했는데,
  아직 어떤식으로 Lab을 꾸려야할지 모르겠어서 해당 community는 LAB에서 생략하겠습니다.  

 

3. Local-as 

  'Do not send outside local AS'라는 의미로, 받은 라우터의 AS에만 광고하라고 하는 Community입니다. 

  마찬가지로 Peer의 동작을 제어하는 기능이며, LAB에서 생략하겠습니다. 이유는 뒤에서 말씀드리겠습니다.  

 

4. no-advertise 

  'Do not advertise to any peer'라는 의미로, 어떤 Peer에게도 전달하지 말라는 의미입니다. 

  Lab에서 다뤄보겠습니다. 

 

5. no-export 

  'Do not export to next AS' 다음 AS로 전달하지말라는 의미로 보이는데, Local-as와 비슷한 동작을 할거라 예상 

 

6. none 

  아무 community attribute도 없음을 의미합니다. 평상시와 동일하므로, 이 community도 생략하겠습니다. 

 

자, 그럼 Lab을 통해 한번 어떻게 Well-known community가 쓰이는지 같이 보시죠. 

 

  


LAB 

 

1) 구성도 

 

보시는바와 같이, 각 라우터들은 표기된 AS에 속해있고, 각각이 eBGP 또는 iBGP로 연결되어있습니다. 

각 라우터에서 광고하는 대역들이 정상적으로 전부 전파되고 있습니다. 

Router1과 2에서의 BGP table을 보고 가겠습니다. 

 

 

Router1의 BGP table

 

Router2의 BGP table

 

 

Community 값 확인하기

 

일단 기본적으로 Router1의 모든 대역이 community 777로 광고되도록 설정해놓은 상태입니다. 

커뮤니티 값이 어떻게 달리는지 보려고 만들어 놓은건데, 이번 #1시나리오에서만 사용하겠습니다. 

 

 

 

시나리오#1 - eBGP로 연결된 구간에서 gshut 발생 시키기 

 

Router1에서 Graceful shutdown을 진행하는데, community 값을 444로 설정해보겠습니다. 

Command는 아래와 같습니다. 

 

<Router1>

router bgp 1

 neighbor 10.10.12.2 shutdown graceful 600 community 444 

 

위 Command의 의미는 600초 후에 Neighbor를 shutdown하는데,  gshut과 더불어 444 community를 포함하라는 의미입니다. 

 

뭔가.. 2개 값이 왔습니다. 

777 그 뒤에 gshut이 붙어있네요 .

순서상은 gshut이 먼저 붙고,그 대역이 광고될때 route-map에 걸리는 것이 맞다고 생각합니다.  

정확히 맞는지는 잘 모르겠지만,, AS-PATH처럼 먼저 발생한 Community값이 뒤로 밀린다고 이해하려 합니다. 

(제가 잘못 이해하고 있는 것이라면 알려주세요) 

 

그러면 저 뒤에 있는 gshut을 Router2에서 community list로 제어했을때, 정상적으로 Filtering이 되는지 확인해보겠습니다. 

Command는 아래와 같습니다. 

 

<Router2>

ip community-list 1 permit gshut

 

route-map test deny 10 

 match community 1 

 

route-map test permit 20  

 

 

gshut이 뒤에 있는대도 정상적으로 Filter가 걸리는 모습을 보실 수 있습니다. 

....

근데 아마 눈치채신분도 있겠지만, 저희는 분명히 community에 444를 추가해서 가도록 변경했는데, 

반영이 안되어있는 모습을 볼 수 있습니다. 

 

두시간 넘게 뻘짓하다가 확인한 내용은 eBGP peer에게 전송할때는 무조건 gshut 하나로만 간다는 겁니다. .

서로 다른 AS간에 협약을 맺은것도 아니고, 굳이 커스터마이징된 Community값을 쓸 필요가 없는거죠. 

 

그럼 이 community는 어디까지 전파가 될까요 ?

저희는 Router1에서 Community 에 777을 붙인 10.10.1.0 대역을 광고하고있습니다. 

iBGP로 연결된 Router5에는 777이 정상적으로 보이고 있네요 ! 

 

 

그렇다면 eBGP로 연결된 다른 라우터는 어떨까요? 

Router3에서 확인해보면 아래와 같이 여전히 777이 보이고 있습니다.. 

이게 몇홉까지 갈지는 잘 모르겠습니다만은 확일한건 'iBGP건 eBGP건 1홉까지는 간다 !'입니다. 

 

 

시나리오#2 - iBGP로 연결된 구간에서 Gshut 발생 시키기 

 

이번에는 Router5에서 graceful shutdown을 발생시켜 정상적으로 Local-preference나 community값을 변경하는지 보겠습니다. 

Command는 아래와 같습니다. 

 

<Router5>

 

router bgp 2

 neighbor 10.10.25.2 shutdown graceful 600 community 444 local-preference 20 

 

 

결과는 iBGP로 연결된 Router2와 다른 AS인 Router1에서 확인해보겠습니다.  

 

Local-preference는 정상적으로 20으로 낮춰졌습니다 

그리고 gshut에 444가 추가로 붙어왔습니다. 이제 뭔가 순리대로 들어오고 있습니다. 

 

그렇다면 Router2와 eBGP로 연결된 AS1에서 확인해보면 어떨까요? 

 

eBGP로 연결된 Peer에서 확인해보면 gshut이 떨어져서 왔습니다. 

걸과적으로 gshut은 eBGP Peer로부터 직접받는다면, iBGP로 전파하고, 다른 AS로 전파하지 않는다. 

그리고 iBGP로부터 gshut을 받았다면, 내부에만 전파하지 외부로는 전파되지 않는다가 결론이겠습니다.

 

시나리오#3 - eBGP로 연결된 구간에서 Local-as 발생 시키기 

시나리오#4 - iBGP로 연결된 구간에서 Local-as 발생 시키기 

 

위 두개는 confederation을 사용하는 구조에서 테스트를 해봐야하는데,

이 부분은 저도 처음들어본 내용이라 추후에 confederation을 설명하는 내용에서 추가로 다뤄보겠습니다. .

 

시나리오#5 - eBGP로 연결된 구간에서 no-advertise 발생 시키기

 

Router1이 자기대역을 광고할때, no-advertise를 붙여서 보내봤습니다. 

한번 각 라우터에서 어떤 결과가 있는지 보겠습니다. 

Command는 아래와 같습니다. 

 

<Router1>

route-map test permit 10 

 set community no-advertise 

 

router bgp 1 

 address-family ipv4 

  neighbor 10.10.12.2 route-map test out 

 

 

Router2에서 확인한 라우팅 테이블과 Community

 

Router5에서 확인한 라우팅 테이블

 

Router3에서 확인한 라우팅 테이블과 Community

 

앞서 설명드린바와 같이, No-advertise를 광고받은 Router2는 iBGP던 eBGP던 모든 Neighbor에게 해당 대역을 광고하지 않습니다.

 

 

시나리오#6 - iBGP로 연결된 구간에서 no-advertise 발생 시키기 

 

이번에는 Router5에서 광고하는 10.10.5.0/24 대역에 대해서 No-advertise를 달고 내보내 보겠습니다. 

Command는 아래와 같습니다. 

 

<Router5>

route-map test permit 10 

 set community no-advertise 

 

router bgp 2

 address-family ipv4 

  neighbor 10.10.25.2 route-map test out 

 

적용한 이후 Router2와 Router1의 BGP table을 보겠습니다. 

 

Router2에서 BGP table 및 Community

 

Router2에서 BGP table

Router5가 Router2에게 광고할때, '어떤 Peer에게도 광고하지마'라는 태그를 붙여보내니,

Router2의 Peer는 해당 광고를 못받고 있는 모습을 보실 수 있습니다. 

 

 

시나리오#7 - eBGP로 연결된 구간에서 no-export 발생 시키기

 

이번에는 eBGP Peer에게 no-export를 전송받는 경우, 광고 받는 라우터에서 어느 구간에 전파를 하는지 확인해보겠습니다.

Command는 아래와 같으며, Router1에 적용하였습니다. 

 

<Router1>

route-map test permit 10

 set community no-export  

 

router bgp 1

 address-family ipv4 

  neighbor 10.10.12.2 route-map test out 

 

 

Router2에서 확인한 BGP table과 community 값
Router5에서 확인한 BGP table과 Community 값
Router3에서 확인한 BGP table

 

위에 보다시피, Router2와 같은 AS를 가진 Router5는 해당 대역을 광고받고있으며, 

AS가 다른 Router3은 광고받지 못하는 모습니다. 

Well-known community는 상당히 신기하네요. 

 

 

시나리오#8 - iBGP로 연결된 구간에서 no-export 발생 시키기 

 

이번에는 iBGP에서 진행을 해보겠습니다. 

Router5에 적용했고, Command는 아래와 같습니다 

 

<Router5>

route-map test permit 10

 set community no-export  

 

router bgp 2

 address-family ipv4 

  neighbor 10.10.25.2 route-map test out 

 

Router2의 BGP table 및 Communtiy 값 확인
Router1의 BGP table

 

예상했던 결과가 나왔습니다. 

iBGP에서 발생한 no-export는 같은 AS내로는 전파가 되고, 다른 AS 즉 eBGP peer에게는 전달이 되지않는것을 보실 수 있습니다. 

 

 


 

맺으며,,

얼마나 편안한 맘으로 끄적이기 시작한 Community 공부였는데, 여태 중 가장 많은 시간이 걸렸습니다. 

 

저는 동적 라우팅을 redistribute하거나 제어할때, 항상 ACL 혹은 Prefix리스트로 하나하나 정의해줘서 다른 동적 라우팅 프로토콜로 넘어가지 못하게 한다던지, 특정 라우팅만 받는다던지, 이런식으로 제어를 해왔었습니다. 

그게 참.. 얼마나 무식한 방법이였다는것을 깨닫는 공부였습니다.  

마킹을 해서 대역들을 묶는다던지, .. 

 

이것만 잘쓰면 마킹을 통한 그룹핑을 할수도 있고, 해당 마킹이 달린 대역을 받았을때, 취할 액션을 정의 한다던지, MPLS망 유지보수 시 적절한 gshut를 뿌려 트래픽을 우회시켜놓는다던지, ACL을 줄여 가독성있는 Configuration을 만들 수도 있습니다. 활용은 무궁무진하지않나 싶습니다. 

 

그리고,, 저는 여태까지 Router당 AS는 1개밖에 없다라고 생각하고 있었습니다. 당연한 상식이였고, 믿어의심치않았는데, 제 세상이 

BGP confederations으로 무너졌습니다

AS아래 sub-AS 후..

언제한번 기회가 된다면 글로벌 회선사업자의 BB 장비 Configuration을 구경해보고 싶습니다 

 

그럼 오늘도 어제보다 꿈에 가까워지셨길 기도하면서, 이만 가보겠습니다.