BGP 하나에 엄청 많은 정보가 있는줄은 알았는데, 이만큼 썻으면 소재가 고갈될 법도 한데, 아직 산더미 같이 남았습니다.
'이제 BGP 조금 안다' 라는 생각에 스스로 떳떳해질 수 있게 마지막까지 달려봅시다
이번 시간에는 BGP의 기능 중 Route-reflector(이하 RR)에 대한 내용을 학습해 볼까 합니다.
추후에 MP-BGP를 활용한 MPLS도 다뤄보려는데, 이를 위해서는 RR에 대한 내용이 반드시 선행되어야하기에,
별도 포스팅으로 다뤄봤습니다.
시작하겠습니다.
1. Route-reflector란 ?
iBGP를 구성할 경우, 가급적 구성해야하는 Full mesh 구성을 대신하기 위하여, RFC 4456에서 정의된 기능
중간에서 Prefix를 동일 AS 다른 라우터들에게 반사해주는 역할
기본적으로 iBGP를 통해 광고받은 대역은 iBGP peer에게 전파하지않으나(루핑을 방지하기 위함),
RR 설정된 Router가 광고받는 경우, 자체 Cluster-ID를 cluster-list에 추가하여 상대에게 광고합니다.
그러면 RR구성에서는 어떻게 루핑을 방지하는지 살펴보겠습니다.
위에 말했던것과 같이, RR을 통해 전달받은 Prefix에는 어느 라우터가 광고했는지를 나타내는 originator 필드와
RR의 Cluster-ID가 Cluster List에 추가되서 전달됩니다 아래와 같이요.
자세한건 LAB에서 살펴보기로 하고, 지금은 이런게 있다 정도만 이해하고 넘어가겠습니다.
당연하게도 RR-client입장에서는 Originator에 자신의 Router-id가 기재되어있는 Prefix의 경우에는 업데이트를 무시합니다.
'내가 원조인데, 왠 다른놈이 자기한테 있다고 광고하는거지 하면서 말이죠. '
만약 MCID(multi-cluster id)를 사용하는 구성이라면, Cluster list에 자신의 Cluster ID를 포함하는 업데이트를 받으면 해당 업데이트는 무시됩니다.
위에 말이 저도 처음에는 어려웠는데, 이렇게 이해하면 쉽더라구요.
eBGP환경이랑 비슷하게 자신이 가진 AS가 들어있는 Prefix를 광고받는다면 해당 업데이트가 무시되는 것과 같이,
해당 Prefix를 광고한 주체가 나거나, 나를 통해 한번이라도 다른 라우터에 광고된 대역이라면, 외부로부터 업데이트가 온다한들 무시해버리는 것이죠.
정말로 라우팅이 변경되었다면, 아직 거치지않은 라우터의 Cluster-id가 prefix내 정보에 포함되어있지 않을것이기 때문에,
루핑을 방지하면서, BGP table을 변경할 수 있는것이죠.
2. Route-reflector 유형
크게 RR에는 3가지 유형이 있습니다.
- 클라이언트와 비클라이언트간
- 동일한 클러스터의 클라이언트 간(클러스터 내)
- 서로 다른 클러스터의 클라이언트 간(클러스터 간)
3번째는 제가 가지고 있는 시뮬레이터 환경에서 Neighbor별 Cluster-id셋팅이 안되서 실습을 진행못한 점, 양해 부탁드립니다.
하나씩 설명하기 전에 구성도부터 보고 가시죠
ㄱ) 클라이언트와 비클라이언트 간
쉽게 말해 위 동일 Cluster에 있는 RR과 S3P1간을 의미합니다.
동일 Cluster에 있는 라우터들의 광고대역을 RR로 모으고 있기 때문에, Cluster를 하나의 거대한 라우터로 봐도 무방하지않나 싶습니다.
S3P1과 RR은 서로가 가지고 있는 BGP table을 광고하죠.
ㄴ) 동일한 클러스터의 클라이언트 간(클러스터 내)
S1P1 과 RR간 을 의미합니다. S1P1등 클라이언트는 RR에게 자기가 광고하고 있는 Prefix들을 광고하고,
RR은 자신이 가지고 있는 AS 1에 해당하는 Prefix를 반사하죠 일부 속성을 추가하면서 말이죠.
ㄷ) 서로다른 클러스터의 클라이언트 간(클러스터 간)
위와 같이 동일한 RR과 iBGP peer를 맺고 있음에도 불구하고, 영역을 구분할 수 있습니다.
구분 짓는 이유는 다양하겠지만 아무래도 전파받고 전파하는 Prefix를 제어하기 위함이 가장 크지 않을까 싶습니다.
Cluster는 RR에서 remote-as를 설정하듯이, 해당 라우터는 1번 그룹의 클러스터다 ~ 하고 정의하는 식 입니다.
예로는 S3P1에서 광고받는 대역들을 Cluster 1에만 광고하고, 2에는 하지않게 할 수 있습니다.
만약 Neighbor별로 Cluster-id가 선언되지않았더라면, RR의 Router-id가 Global Cluster ID가 됩니다
이때는 MCID(Multi cluster ID) 환경이 아니라고 할 수 있겠습니다.
그러면 이제 Lab을 진행해보겠습니다.
1. 구성도
접두사 S1, S2가 RR의 Client들이고, S3P1은 RR과 일반적인 iBGP peer입니다.
각각은 자신이 가지고 있는 Loopback ip를 광고하고있는 상황이고, 연결에는 문제가 없습니다.
2. 설명
우선 Client입장에서 한번 보도록 하곘습니다.
아래는 S1P1의 BGP table과 routing table입니다.
동일 Cluster에 있는 라우터건, 비클라이언트인 라우터 S3P1이던지,
각 라우터에서 광고하는 모든 대역들이 BGP table에 올라와있는 것을 볼 수 있습니다.
*짤막하게 복습하는 의미로 192.168.1.2는 자기가 network로 선언한 대역이라, Weight가 32768 달려있는 모습을 보실 수 있습니다.
그리고 말씀드리고 싶었던 내용은 라우팅 테이블입니다.
분명 RR로부터 모든 라우터에서 광고하고 있는 대역을 전부 받아왔지만, 라우팅테이블로 올라간 대역이 아무것도 없습니다.
192.168.1.2.는 Loopback interface를 설정한 후에 Network선언을 해준것이라 Connected로 올라가 있습니다.
이유는 단순합니다.
iBGP에서는 Next-hop을 BGP speaker의 IP로 바꿔서 광고하지 않기때문에,
S1P1의 입장에서는 Next-hop에 대한 경로가 없는 대역들을 광고받아 라우팅 테이블로 올리지 않습니다.
*여기서 만약에 Next-hop에 대한 라우팅을 Static이던 다른 라우팅 프로토콜이던지 정의를 해주면 라우팅 테이블로 올라오게 됩니다.
(중요)이 부분은 RR환경에서 OSPF나 EIGRP등 다른 내부 동적 라우팅 프로토콜을 혼용해서 사용하는 이유입니다.
MPLS를 설명할때도 나올 예정이니, 꼭 기억해주세요
이어서 개별 Prefix에 대해서 하나씩 살펴보겠습니다.
S1P1에서 광고하는 192.168.1.2를 보면 자신이 광고하고 있다는내용과 더불어,
Advertised to update-groups에 1이라고 되어있는 것을 보실 수 있습니다.
이는 해당 Prefix가 어떤 그룹에 전달되고 있는지를 명시하고 있고,
Update-group 1을 자세히보면 10.10.1.1 의 member에게 광고하고 있습니다.
*10.10.1.1은 RR입니다.
결론은 '192.168.1.2는 자신이 만들어낸 Prefix이고, RR에게 광고중이다'가 됩니다.
그렇다면 S1P2가 만든 192.168.1.3은 어떨까요?
주목해야할 부분은 3가지입니다.
- Not advertised to any peer
- 10.10.2.2 (inaccessible)
- Originator & Cluster list
1. 일단 해당 대역은 자기가 만든 대역이 아니라 iBGP peer(RR)로부터 광고받은 대역이기에, 아무 그룹에게도 광고하지않습니다.
2. 그리고 10.10.2.2가 Next-hop이지만 Routing table에 경로가 없기때문에, inaccessible처리 되었습니다.
3. 마지막으로 해당 Prefix의 출처는 192.168.1.3 이고, Cluster list에는 RR의 Router-id가 들어있습니다.
가독성있게 Loopback ip를 광고했더니, prefix하고 Originator가 같아서 헷갈리지않게 주의해야할것 같습니다.
이제 RR의 입장에서 한번 확인해보겠습니다.
BGP로 받아온 대역들이 모두 Routing table로 올라와있습니다. 왜냐하면, Next-hop에 대한 라우팅이 있기때문입니다. ( Connected)
세부 Prefix하나 찝어서 확인해보겠습니다.
192.168.1.2는 S1P1이 광고하는 대역이였죠
이번에는 Update-groups이 1과 2가 있어 모두 확인해봤습니다.
차이는 동일 Cluster로 묶인 Peer들을 별도 그룹으로, 비클라이언트 Neighbor을 하나의 그룹으로, 따로따로 설정되어있습니다.
전부다 그냥 뿌리는줄 알았는데, 이런식으로 그룹화를 해서 뿌리는지는 몰랐습니다.
혹시 몰라서 S1P2를 별도의 Peer-group으로 설정해봤는데도, Update-group은 위와 동일했으니, 동일한 RR client끼리 묶인다고 생각해주시면 됩니다.
그러면 RR에서 비클라이언트인 S3P1이 광고하는 192.168.5.1 대역을 한번 보겠습니다.
특이한게 한가지 있습니다.
RR 입장에서 S3P1은 iBGP peer입니다. 따라서 iBGP peer에게 전달받은 Prefix는 iBGP peer에게 광고하면 안됩니다. (루핑방지)
근데 update-group 1에게는 광고하고 있는것을 보실 수 있습니다.
앞서도 말했지만 같은 Cluster ID를 가진 라우터들은 큰 1개의 라우터 취급을 해야한다 라는 내용이였는데,
RR이 받은 Prefix는 자신의 Client에게 광고가 아니라 반사해준다는 개념으로 이해하면 도움되실 겁니다.
자 이제 비클라이언트인 S3P1입장에서 한번 보겠습니다.
마찬가지로 eBGP가 아니기 때문에, Next-hop이 전혀 안바뀌어 있습니다.
그렇기에 S1, S2 라우터들이 광고하는 대역이 전부 Routing table에 없습니다.
그러면 한번 RR에서 Next-hop-self로 전달해보겠습니다. (왜 하는지는 뒤에서 설명하겠습니다. )
전 분명히 RR에서 아래 Command를 했습니다.
router bgp 1
address-family ipv4
neighbor 10.10.5.2 next-hop-self
제가 아는 상식선에서는 적용 되었어야할 Config에서 아무리 Clear를 몇번을 해봐도 Next-hop이 바뀌지않았습니다.
사실 RR은 라우팅의 반사를 위함이지, 모든 iBGP 라우터들이 경유해야할 라우터가 아닙니다.
따라서 위와같이 BGP config에서 RR Client에서 받아온 대역의 Next-hop의 변경은 불가하지않나 싶습니다.
그래서 아래 명령어를 통해서,
BGP process에서 Next-hop을 바꾸지못한다면, Outbound route-map을 걸어서 강제로 바꿔보자 했습니다.
route-map test permit 10
set ip next-hop self
router bgp 1
address-family ipv4
neighbor 10.10.5.2 route-map test out
결과는 .. 성공입니다.
보시다시피, BGP table에서 Next-hop을 보시면 바뀌어져있는것을 확인하실 수 있습니다.
하지만 이는 LAB이기 떄문에 적용해본것이고, 실상황에서 저런식으로 Next-hop을 변경해버리면, 모든 경로를 RR로 거쳐갈 뿐더러,
의도치않은 side-impact로 루핑이 돌 수 있기때문에, 왠만하면 사용하지않는것을 추천합니다.
RR로부터 받은 경로를 Routing table로 올리고 싶다면, 강제로 Next-hop을 변경하는 안보다는,
위에서 언급했다시피, 별도의 Dynamic routing protocol을 통하여 Next-hop에 대한 경로를 알게하는것이 더 좋아보입니다.
맺으며,
항상 시작할때는 LAB도 꾸려놨겠다, 하나씩 쓰면서 글만 끄적이면 한시간이면 쓰겠지..하지만,
이건 어떻지 저건 또 어떻지 하다보면 2시간은 금방 지나가는것같습니다.
오늘부터 CCIE 시험을 준비하려고 출제 범위를 뽑아봤는데, 10%도 제대로 설명할줄 아는게 없는것 같아서,
잠깐 BGP는 쉬어가고, CCIE 범위 내용을 하나씩 공부하고 시간되는대로 포스팅을 하겠습니다.
그렇다고 여태 게시한 내용이 CCIE 범위가 아니라는 말은 아닙니다.
의도치않았지만 모든 내용이 범위가 맞습니다만,, 정말 일부라서 민망할 정도입니다. .
만약에 추가로 뭘좀 해달라고 댓글로 적어주시면 공부는 재껴놓고 포스팅을 우선하겠습니다.
모두 행복하시고, 앞으로 진행할 내용도 재밌고 도움되는 것들이 많으니 재밋게 봐주시면 좋겠습니다.
'Network 모험기' 카테고리의 다른 글
| [L2]FHRP(VRRP, HSRP, GLBP)에 대한 간단한 이해 (4) | 2024.11.02 |
|---|---|
| [L2]VTP와 MST 연계 구성 (3) | 2024.10.28 |
| [#3-6]BGP aggregate 활용하기 (0) | 2024.03.16 |
| [#3-5]BGP Community 활용하기 (1) | 2024.03.14 |
| [#3-4]BGP AS-override, allowas-in 활용하기 (0) | 2024.03.10 |
