Cloud Networking
Techs( younjin.jeong@gmail.com, 정윤진 )
네트워킹에 대한 글은 참 오랜만에 써 보는 것 같다. 사실 그다지 잘 아는 분야도 아니거니와, 일반적인 L3 ip networking 이 거의 대부분의 사용성을 지배하는 한국에서는 너무 당연한 이야기들이 많아서 쓸 것이 없어 그랬지 않았나 싶기도 하다.
오늘 잠깐 생각해 볼 주제는, 클라우드 네트워킹에서 가장 중요한 '확장성'을 고려하게 될 때, 과연 어떻게 망을 구성해야 효과적일까 하는 것이다. 모두들 넌블러킹 스위칭에 대해서 이야기 하고 있지만, 실제 그 넌블러킹의 정체가 무언지, 또 그렇다면 어떤 장비를 어떻게 엮어야 그런 확장성을 이루어 낼 수 있는지에 대해서 디테일하게 이야기 해 보기란 쉽지 않은 일일것이다.
일반적으로 구성하는 ipSAN 또는 스토리지간 연결을 위한 내부 폐쇠망의 구성을 하는데 있어, 최소한 랙 500 대 이상을 확장 할 수 있어야 한다 라는 요구사항이 있을때, 이 구간의 연결 및 IP 정책을 어떻게 만들어 낼 것인가가 아마도 최대의 고민이 될 수 있을 것이다. 경력있는 네트워크 엔지니어는 이러한 경우 내부망을 위한 전용 백본을 구성하고, 이 백본에서 하위 Aggregation 스위치로 MLAG, 다시 ToR ( Top of Rack ) 스위치로의 MLAG 구성을 만드는 것이 일반적인 구성이 될 수 있겠다.
Image from: http://www.computer-room-design.com/Arista-Networks-7500-Series-Data-Center-Switch.asp
흔히 MLAG 이라 불리는 이러한 기술은, 여러대의 스위치를 한대의 스위치로 묶어 L2 레벨의 사용성을 보장한다. 이러한 구성은 최근의 대부분의 벤더가 지원하지만, 특정 벤더별로 상위 스위치로 연결된 2 또는 그 이상의 trunk 된 회선을 동시에 사용하는 이른바 Multi-path 를 지원하거나 지원하지 않는 제품들이 있다. 또한, 이렇게 사용하게 될 때 보통 각 랙별로 별도의 분리된 네트워크를 사용하고자 하는 경우가 많은데, 이럴때 각 ToR 을 위한 VLAN 구성을 추가하게 된다면 이제 각 VLAN 별로 게이트웨이가 되는 IP 를 할당해 주어야 할 텐데, 여기서 또 한번 할당 할 수 있는 IP 수량에 대한 제약 사항이 발생하게 된다.
이와는 별도로 ToR 의 이중화 구성에 대해서 궁금해 하시는 분들도 있겠지만, 현대의 대부분의 클라우드 시스템들은 랙 하나의 장애에 크게 구애받지 않는다. 따라서 Aggregation 또는 백본의 장애에 대해서만 MLAG 을 구현하고, ToR 은 랙 별로 하나만 두기 때문에 위의 그림에서는 ToR 스위치가 한대다. 물론, 비용을 보다 많이 사용 할 수 있다면 모든 구성에 이중화가 가능하겠다.
아무튼 원래 주제인 MLAG 으로 돌아가서, ToR 에서는 L2, Aggregation 에서 L3 를 구현하는 이러한 방법은 여러모로 확장에 제한을 받게 된다. 물론 이러한 확장의 제한이라는 것이, 보통 샤시 레벨의 제품군을 사용하게 된다면 수백개의 포트 단위까지는 충분히 허용이 가능하므로, 구성하려는 시스템의 규모에 따라 제약사항이 되지 않을 가능성이 있다. 아니, 지금까지는 보통 그래왔다.
게다가 샤시 레벨의 제품을 사용하지 않는 경우에도, Aggregation 의 구성에 Tier 를 적용함으로서 48포트 X 48포트의 구성을 하는 것도 가능하다. 최근의 몇몇 벤더에서는 업링크에 40G 를 지원하는 제품도 있으므로, 이러한 구성시 보다 여유로울 수 있겠다.
얼마 전 까지만 해도 나 역시 이러한 구성이 거의 유일한 해법이며, 넌블러킹 구성에 있어 이보다 좋은 다른 대안이 없는 것으로 생각하고 있었다. MLAG 구성에서 Multi-path 를 지원 할 수 있다면, 현존하는 가장 좋은 내부망 확장 방법이라고 생각 했었다.
하지만 최근, 일본의 Midokura ( www.midokura.com )의 Dan 과 Ryu 와 함께 일하게 되면서 새로 배운 것이 있는데, 바로 내부망에 라우팅 프로토콜인 BGP 를 사용하는 방법이다.
사실 국내에서 네트워크 전문가가 아니라면 생소한 이 프로토콜은, 보통 AS라 불리는 별도의 망 단위간 네트워크에서 라우팅을 위해 사용된다. 국내에서 생소한 이유는, 보통 이 AS가 데이터센터에 입주한 고객에게 별도로 할당되는 경우가 매우 드물고, 따라서 고객이 데이터센터의 ISP 와의 연결에 Static 라우팅을 사용하는 경우가 대부분이기 때문이다. 실제 수년간 필드에서 잔뼈가 굵으신 엔지니어 분들 께서도 BGP 구성에 직접 참여하게 되면 먼지쌓인 책을 다시 살펴봐야 하는 경우가 허다 했다.
어쨌든 이는 라우팅 프로토콜이기 때문에, 라우터 A 에서 라우터 Z 로 가기 위한 여러개의 경로를 동적으로 할당하는 것이 가능해 진다. 물론 이러한 목적을 위해 BGP 만 존재하는 것은 아니며, RIP, OSPF 등의 수많은 프로토콜이 존재한다. 그런데 왜 여기서 갑자기 BGP를 꺼내들었는가. 그 이유를 살펴 보자.
1. 최근 데이터 센터 구성에 사용하는 24-48 포트 10G 스위치는 L3 기반인 경우가 많고, 이 L3 스위치들은 BGP 운용이 가능하다. 바꾸어 말하면, 10G 24-48 포트 라우터로 사용 할 수 있다.
2. iBGP 를 사용하여 Backbone / Aggregation 을 클라우드 망으로 구성할 수 있다. 무슨 이야기인고 하니, 모든 스위치가 라우터로 동작 하므로, 어느 한 지점의 장애에 구애 받지 않게 된다.
3. ECMP 를 사용하여 수없이 발생하게 될 경로에 대한 최대한의 대역폭 사용이 가능해 진다.
4. 장애가 발생한 경우 그 전파가 매우 빠르고, 전체 망이 한꺼번에 다운될 확률이 낮아진다.
5. 각 랙에서 발생하는 L2 통신은 랙 내부로 고립되고, 이 랙에서 돌리는 각 VM의 상태가 백본 레벨로 전달 될 염려가 없다. 랙 장애는 랙 장애에 국한된다.
6. 일단 백본이 구성되고 나면, 어느 경로에든 ToR 을 원하는 형태로 가져다 붙일 수 있다. 따라서 진정한 Scale-out 이 사용 가능한 IP 대역이 떨어질 때 까지 확장 가능하다.
위의 장점 이외에도, 다른 수많은 장점이 있을 수 있다고 본다. 물론 굳이 iBGP 가 아니라, 각 랙에 사설 AS 를 할당하여 백본과 eBGP를 구성하는 방법도 있을 수 있다. 어떠한 구성의 방법이 더 좋은지의 여부는 네트워크 벤더별로 다를 수 있으며, 경우에 따라 ECMP 를 원활하게 지원하지 않는 경우도 있으니 확인을 꼭 해 볼일이다.
현재 일을 하고 있는 회사에서 국내에 Arista 를 배포하고 있어, 장비를 가져다가 테스트 해 볼 수 있었다.
테스트 환경은,
- Arista 7124SX 5대
- 일반 Quanta 서버 3대
였으며, 테스트를 위한 컨셉은 다음과 같다.
그림은, 각 랙은 서로 다른 24bit 의 네트워크를 가지며, ToR 을 지나는 순간 iBGP 를 사용하여 다른 랙으로 라우팅 된다. 이때 ToR 회서는 각각의 백본에 연결되며, 이 서로 다른 라우팅 Path 에 모두 ECMP 를 적용하게 된다.
컨셉이 이렇다면, 실제 백본의 할당은 다음과 같다.
172 네트워크는 관리를 위한 별도의 망이며, 구성된 모든 장치에 연결되어 있다. 실제 트래픽은 푸른색의 회선을 통해 실리게 된다. 이렇게 환경에 대한 구성이 끝났다면, 이제 실제 각 스위치를 설정한다.
백본은 백본끼리 서로 동일하며, ToR 설정은 각각 모두 동일하기 때문에 샘플로 하나씩만 싣도록 한다.
먼저, Backbone #1 의 설정
이제, ToR #1 의 설정을 살펴보자.
이렇게 설정하게 되면, 위의 다이어그램과 같이 원하는 대로 망이 동작하게 된다. 아래의 스크린샷은 각 스위치에 sflow 를 걸어두고, 서버 1대에서 다른 2개의 ToR 로 트래픽을 발생 시켰을 때 볼 수 있는 그림이다.
네트워킹을 전문으로 하시는 분이라면 위의 null0 라우팅 부분을 의아하게 생각 하실 수 있겠다. 이는 이렇게 구성된 망이 폐쇠망이고 외부로 별도의 경로가 없기 때문에, 모든 ToR 에 default 라우팅을 전파하기 위해 별도로 구성된 설정으로 이해 해 주시면 된다. 또한, 경우에 따라 백본에 neighbor x.x.x.x route-reflect-client 를 구성하여 모든 ToR 에 다른 ToR 의 경로를 전파 할 수도 있겠다. 물론 여기서는 어쨌든 백본으로 모든 트래픽을 보내기 때문에, 백본에서 별도로 RR-client 설정을 넣어 주지는 않았다.
ToR 에서 살펴본 ip routing 정보.
이러한 스위치가 가지는 장점을 백분 활용함으로서 해 볼 수 있는 것들은 정말로 많이 있다.
기존에는 생각하지 못했던 방법, 보다 스케일링이 가능한 방법.
네트워크 엔지니어만 알고 있어서 되는게 아니고, 서버 엔지니어라고 해서 네트워크를 모르면 안되는 것과 같은 이치이다. 한 구간만 생각한다면 이러한 룰이 나올 수 있을리 없다고 생각한다.
최근 클라우드 아키텍팅에서의 트렌드는, 기존의 L2 + L3 구성을 버리고 모두 L3 를 사용하는 방법이다. 위의 설정은 단순히 이러한 구성 및 컨셉을 확인하기 위한 용도에 지나지 않으며, 서비스에 구성하기 위해서는 보다 나은 timer 설정등이 필요하게 될 것이다. 또한, 백본을 다중화 하는 방법도 충분히 실현이 가능하다.
이 포스팅에 굳이 MLAG 구성의 그림을 넣지 않은 이유는, BGP 의 활용에 대해서 더 살펴보기 위함이었다. 필요하신 분들 께서는 구글에서 MLAG 이라는 검색어만 넣어도 수없이 많이 떠오르는 내용을 보실 수 있을 것이다.
본 설정을 완료하기 위해 도움을 주신 분들이 계시다. 간단히 소개를 해 보자면,
Dan Mihai Dumitriu ( CEO/CTO at Midokura )
Nishizawa, Satoshi ( Network expert at Midokura )
이정호 차장님 ( Arista Korea )
또한, 고생 해 준 우리 장비들에게도 쌩유.
네트워킹에 고민하고 계신 분들께 조금이나마 도움이 되었으면 하며, 혹시라도 가져가실때는 출처를 남겨 주시길.
조만간 eBGP 도 테스트 해 볼 예정.
( younjin.jeong@gmail.com, 정윤진 )
네트워킹에 대한 글은 참 오랜만에 써 보는 것 같다. 사실 그다지 잘 아는 분야도 아니거니와, 일반적인 L3 ip networking 이 거의 대부분의 사용성을 지배하는 한국에서는 너무 당연한 이야기들이 많아서 쓸 것이 없어 그랬지 않았나 싶기도 하다.
오늘 잠깐 생각해 볼 주제는, 클라우드 네트워킹에서 가장 중요한 '확장성'을 고려하게 될 때, 과연 어떻게 망을 구성해야 효과적일까 하는 것이다. 모두들 넌블러킹 스위칭에 대해서 이야기 하고 있지만, 실제 그 넌블러킹의 정체가 무언지, 또 그렇다면 어떤 장비를 어떻게 엮어야 그런 확장성을 이루어 낼 수 있는지에 대해서 디테일하게 이야기 해 보기란 쉽지 않은 일일것이다.
일반적으로 구성하는 ipSAN 또는 스토리지간 연결을 위한 내부 폐쇠망의 구성을 하는데 있어, 최소한 랙 500 대 이상을 확장 할 수 있어야 한다 라는 요구사항이 있을때, 이 구간의 연결 및 IP 정책을 어떻게 만들어 낼 것인가가 아마도 최대의 고민이 될 수 있을 것이다. 경력있는 네트워크 엔지니어는 이러한 경우 내부망을 위한 전용 백본을 구성하고, 이 백본에서 하위 Aggregation 스위치로 MLAG, 다시 ToR ( Top of Rack ) 스위치로의 MLAG 구성을 만드는 것이 일반적인 구성이 될 수 있겠다.
MLAG ( Multi-chassis Link Aggregation )
Image from: http://www.computer-room-design.com/Arista-Networks-7500-Series-Data-Center-Switch.asp
흔히 MLAG 이라 불리는 이러한 기술은, 여러대의 스위치를 한대의 스위치로 묶어 L2 레벨의 사용성을 보장한다. 이러한 구성은 최근의 대부분의 벤더가 지원하지만, 특정 벤더별로 상위 스위치로 연결된 2 또는 그 이상의 trunk 된 회선을 동시에 사용하는 이른바 Multi-path 를 지원하거나 지원하지 않는 제품들이 있다. 또한, 이렇게 사용하게 될 때 보통 각 랙별로 별도의 분리된 네트워크를 사용하고자 하는 경우가 많은데, 이럴때 각 ToR 을 위한 VLAN 구성을 추가하게 된다면 이제 각 VLAN 별로 게이트웨이가 되는 IP 를 할당해 주어야 할 텐데, 여기서 또 한번 할당 할 수 있는 IP 수량에 대한 제약 사항이 발생하게 된다.
이와는 별도로 ToR 의 이중화 구성에 대해서 궁금해 하시는 분들도 있겠지만, 현대의 대부분의 클라우드 시스템들은 랙 하나의 장애에 크게 구애받지 않는다. 따라서 Aggregation 또는 백본의 장애에 대해서만 MLAG 을 구현하고, ToR 은 랙 별로 하나만 두기 때문에 위의 그림에서는 ToR 스위치가 한대다. 물론, 비용을 보다 많이 사용 할 수 있다면 모든 구성에 이중화가 가능하겠다.
아무튼 원래 주제인 MLAG 으로 돌아가서, ToR 에서는 L2, Aggregation 에서 L3 를 구현하는 이러한 방법은 여러모로 확장에 제한을 받게 된다. 물론 이러한 확장의 제한이라는 것이, 보통 샤시 레벨의 제품군을 사용하게 된다면 수백개의 포트 단위까지는 충분히 허용이 가능하므로, 구성하려는 시스템의 규모에 따라 제약사항이 되지 않을 가능성이 있다. 아니, 지금까지는 보통 그래왔다.
게다가 샤시 레벨의 제품을 사용하지 않는 경우에도, Aggregation 의 구성에 Tier 를 적용함으로서 48포트 X 48포트의 구성을 하는 것도 가능하다. 최근의 몇몇 벤더에서는 업링크에 40G 를 지원하는 제품도 있으므로, 이러한 구성시 보다 여유로울 수 있겠다.
얼마 전 까지만 해도 나 역시 이러한 구성이 거의 유일한 해법이며, 넌블러킹 구성에 있어 이보다 좋은 다른 대안이 없는 것으로 생각하고 있었다. MLAG 구성에서 Multi-path 를 지원 할 수 있다면, 현존하는 가장 좋은 내부망 확장 방법이라고 생각 했었다.
하지만 최근, 일본의 Midokura ( www.midokura.com )의 Dan 과 Ryu 와 함께 일하게 되면서 새로 배운 것이 있는데, 바로 내부망에 라우팅 프로토콜인 BGP 를 사용하는 방법이다.
사실 국내에서 네트워크 전문가가 아니라면 생소한 이 프로토콜은, 보통 AS라 불리는 별도의 망 단위간 네트워크에서 라우팅을 위해 사용된다. 국내에서 생소한 이유는, 보통 이 AS가 데이터센터에 입주한 고객에게 별도로 할당되는 경우가 매우 드물고, 따라서 고객이 데이터센터의 ISP 와의 연결에 Static 라우팅을 사용하는 경우가 대부분이기 때문이다. 실제 수년간 필드에서 잔뼈가 굵으신 엔지니어 분들 께서도 BGP 구성에 직접 참여하게 되면 먼지쌓인 책을 다시 살펴봐야 하는 경우가 허다 했다.
어쨌든 이는 라우팅 프로토콜이기 때문에, 라우터 A 에서 라우터 Z 로 가기 위한 여러개의 경로를 동적으로 할당하는 것이 가능해 진다. 물론 이러한 목적을 위해 BGP 만 존재하는 것은 아니며, RIP, OSPF 등의 수많은 프로토콜이 존재한다. 그런데 왜 여기서 갑자기 BGP를 꺼내들었는가. 그 이유를 살펴 보자.
1. 최근 데이터 센터 구성에 사용하는 24-48 포트 10G 스위치는 L3 기반인 경우가 많고, 이 L3 스위치들은 BGP 운용이 가능하다. 바꾸어 말하면, 10G 24-48 포트 라우터로 사용 할 수 있다.
2. iBGP 를 사용하여 Backbone / Aggregation 을 클라우드 망으로 구성할 수 있다. 무슨 이야기인고 하니, 모든 스위치가 라우터로 동작 하므로, 어느 한 지점의 장애에 구애 받지 않게 된다.
3. ECMP 를 사용하여 수없이 발생하게 될 경로에 대한 최대한의 대역폭 사용이 가능해 진다.
4. 장애가 발생한 경우 그 전파가 매우 빠르고, 전체 망이 한꺼번에 다운될 확률이 낮아진다.
5. 각 랙에서 발생하는 L2 통신은 랙 내부로 고립되고, 이 랙에서 돌리는 각 VM의 상태가 백본 레벨로 전달 될 염려가 없다. 랙 장애는 랙 장애에 국한된다.
6. 일단 백본이 구성되고 나면, 어느 경로에든 ToR 을 원하는 형태로 가져다 붙일 수 있다. 따라서 진정한 Scale-out 이 사용 가능한 IP 대역이 떨어질 때 까지 확장 가능하다.
위의 장점 이외에도, 다른 수많은 장점이 있을 수 있다고 본다. 물론 굳이 iBGP 가 아니라, 각 랙에 사설 AS 를 할당하여 백본과 eBGP를 구성하는 방법도 있을 수 있다. 어떠한 구성의 방법이 더 좋은지의 여부는 네트워크 벤더별로 다를 수 있으며, 경우에 따라 ECMP 를 원활하게 지원하지 않는 경우도 있으니 확인을 꼭 해 볼일이다.
현재 일을 하고 있는 회사에서 국내에 Arista 를 배포하고 있어, 장비를 가져다가 테스트 해 볼 수 있었다.
테스트 환경은,
- Arista 7124SX 5대
- 일반 Quanta 서버 3대
였으며, 테스트를 위한 컨셉은 다음과 같다.
iBGP Test Concept
그림은, 각 랙은 서로 다른 24bit 의 네트워크를 가지며, ToR 을 지나는 순간 iBGP 를 사용하여 다른 랙으로 라우팅 된다. 이때 ToR 회서는 각각의 백본에 연결되며, 이 서로 다른 라우팅 Path 에 모두 ECMP 를 적용하게 된다.
컨셉이 이렇다면, 실제 백본의 할당은 다음과 같다.
IP Allocation
172 네트워크는 관리를 위한 별도의 망이며, 구성된 모든 장치에 연결되어 있다. 실제 트래픽은 푸른색의 회선을 통해 실리게 된다. 이렇게 환경에 대한 구성이 끝났다면, 이제 실제 각 스위치를 설정한다.
백본은 백본끼리 서로 동일하며, ToR 설정은 각각 모두 동일하기 때문에 샘플로 하나씩만 싣도록 한다.
먼저, Backbone #1 의 설정
.... ... .. interface Ethernet1 no switchport ip address 10.100.100.18/30 ! interface Ethernet2 ! interface Ethernet3 .... .. ! interface Ethernet22 ! interface Ethernet23 no switchport ip address 10.100.100.1/30 ! interface Ethernet24 no switchport ip address 10.100.100.5/30 ! interface Management1 ip address 172.17.17.91/24 ! ip route 0.0.0.0/0 Null0 255 ! ip routing ! router bgp 100 bgp log-neighbor-changes neighbor 10.100.100.2 remote-as 100 neighbor 10.100.100.2 update-source Ethernet23 neighbor 10.100.100.2 maximum-routes 12000 neighbor 10.100.100.6 remote-as 100 neighbor 10.100.100.6 update-source Ethernet24 neighbor 10.100.100.6 maximum-routes 12000 neighbor 10.100.100.17 remote-as 100 neighbor 10.100.100.17 update-source Ethernet1 neighbor 10.100.100.17 maximum-routes 12000 network 0.0.0.0/0 ! management telnet no shutdown ! ! end
이제, ToR #1 의 설정을 살펴보자.
..... ... . vlan 10 ! interface Port-Channel10 switchport access vlan 10 ! interface Ethernet1 switchport access vlan 10 channel-group 10 mode active ! interface Ethernet2 switchport access vlan 10 channel-group 10 mode active ! interface Ethernet3 switchport access vlan 10 ! ..... ... .. ! interface Ethernet22 switchport access vlan 10 ! interface Ethernet23 no switchport ip address 10.100.100.2/30 ! interface Ethernet24 no switchport ip address 10.100.100.14/30 ! interface Management1 ip address 172.17.17.93/24 ! interface Vlan10 ip address 10.1.1.254/24 ! ip routing ! router bgp 100 bgp log-neighbor-changes timers bgp 30 90 maximum-paths 2 ecmp 2 neighbor 10.100.100.1 remote-as 100 neighbor 10.100.100.1 maximum-routes 12000 neighbor 10.100.100.13 remote-as 100 neighbor 10.100.100.13 maximum-routes 12000 network 10.1.1.0/24 ! management telnet no shutdown ! ! end
이렇게 설정하게 되면, 위의 다이어그램과 같이 원하는 대로 망이 동작하게 된다. 아래의 스크린샷은 각 스위치에 sflow 를 걸어두고, 서버 1대에서 다른 2개의 ToR 로 트래픽을 발생 시켰을 때 볼 수 있는 그림이다.
sflow when 2 paths from single server
네트워킹을 전문으로 하시는 분이라면 위의 null0 라우팅 부분을 의아하게 생각 하실 수 있겠다. 이는 이렇게 구성된 망이 폐쇠망이고 외부로 별도의 경로가 없기 때문에, 모든 ToR 에 default 라우팅을 전파하기 위해 별도로 구성된 설정으로 이해 해 주시면 된다. 또한, 경우에 따라 백본에 neighbor x.x.x.x route-reflect-client 를 구성하여 모든 ToR 에 다른 ToR 의 경로를 전파 할 수도 있겠다. 물론 여기서는 어쨌든 백본으로 모든 트래픽을 보내기 때문에, 백본에서 별도로 RR-client 설정을 넣어 주지는 않았다.
ToR 에서 살펴본 ip routing 정보.
TOR-1#sh ip route 0.0.0.0/0
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, A - Aggregate
Gateway of last resort:
B I 0.0.0.0/0 [200/0] via 10.100.100.1
via 10.100.100.13
이러한 스위치가 가지는 장점을 백분 활용함으로서 해 볼 수 있는 것들은 정말로 많이 있다.
기존에는 생각하지 못했던 방법, 보다 스케일링이 가능한 방법.
네트워크 엔지니어만 알고 있어서 되는게 아니고, 서버 엔지니어라고 해서 네트워크를 모르면 안되는 것과 같은 이치이다. 한 구간만 생각한다면 이러한 룰이 나올 수 있을리 없다고 생각한다.
최근 클라우드 아키텍팅에서의 트렌드는, 기존의 L2 + L3 구성을 버리고 모두 L3 를 사용하는 방법이다. 위의 설정은 단순히 이러한 구성 및 컨셉을 확인하기 위한 용도에 지나지 않으며, 서비스에 구성하기 위해서는 보다 나은 timer 설정등이 필요하게 될 것이다. 또한, 백본을 다중화 하는 방법도 충분히 실현이 가능하다.
이 포스팅에 굳이 MLAG 구성의 그림을 넣지 않은 이유는, BGP 의 활용에 대해서 더 살펴보기 위함이었다. 필요하신 분들 께서는 구글에서 MLAG 이라는 검색어만 넣어도 수없이 많이 떠오르는 내용을 보실 수 있을 것이다.
본 설정을 완료하기 위해 도움을 주신 분들이 계시다. 간단히 소개를 해 보자면,
Dan Mihai Dumitriu ( CEO/CTO at Midokura )
Nishizawa, Satoshi ( Network expert at Midokura )
이정호 차장님 ( Arista Korea )
또한, 고생 해 준 우리 장비들에게도 쌩유.
Arista 7124SX
네트워킹에 고민하고 계신 분들께 조금이나마 도움이 되었으면 하며, 혹시라도 가져가실때는 출처를 남겨 주시길.
조만간 eBGP 도 테스트 해 볼 예정.
( younjin.jeong@gmail.com, 정윤진 )
