Loading the catalog…
Loading the catalog…
MLAG와 VRRP를 함께 쓰는 환경에서 트래픽이 어떻게 흐르는지, 벤더 교육 자료의 도식을 보고 EVE-NG에서 직접 구성해서 확인해봤습니다. 상향 트래픽은 자료와 같았는데 하향 트래픽은 실제 동작과 다르다고 판단했고, 실습하면서 MAC 테이블에서 재미있는 점도 하나 발견했어요. 먼저 구성 MLAG로 묶인 스위치 두 대(Primary, Secondary)가 있고, VRRP로 게이트웨이를 이중화합니다. VRRP는 Active-Standby로 동작하니 Primary가 게이트웨이 역할(master)을 맡아요. 위쪽에는 L3 장비가 두 스위치에 모두 연결되어 있고, 아래쪽 서버는 MLAG 포트로 두 스위치에 이중 연결됩니다. 트래픽 방향은 이렇게 부르겠습니다. 상향 트래픽 : 서버 → L3 장비 (다른 대역으로 나가는 트래픽) 하향 트래픽 : L3 장비 → 서버 왼쪽이 상향, 오른쪽이 하향 트래픽입니다. 상향 트래픽은 서버가 게이트웨이로 보내는 트래픽이라 라우팅을 Primary가 처리하고, 서버의 트래픽이 LAG 분산 때문에 Secondary로 들어오면 peer-link를 거쳐 Primary로 넘어가요(점선). 반면 하향 트래픽은 Primary든 Secondary든 서버로 직접 전달합니다. 아래에서 이 부분을 자세히 보겠습니다. 발견 1: Secondary도 트래픽을 처리한다 VRRP가 Active-Standby로 동작하는 건 맞습니다. 하지만 그렇다고 Standby 스위치가 아무것도 못 하는 건 아니에요. VRRP의 핵심은 서버가 다른 대역으로 나가려고 게이트웨이(VIP)로 보내는 트래픽, 즉 라우팅이 필요한 트래픽은 모두 Primary를 거친다 는 점입니다. 위 그림의 상향 트래픽이 여기에 해당해요. 하향 트래픽은 다릅니다. MLAG 스위치 두 대와 서버는 L2로 연결되어 있어서, Secondary도 ARP를 통해 서버의 IP와 MAC을 이미 알고 있어요. 그래서 ECMP로 하향 트래픽이 Secondary 쪽으로 들어오더라도, peer-link로 Primary에 넘기지 않고 바로 서버로 보낼 수 있습니다. EVE-NG에서 실습하면서 Secondary가 이렇게 트래픽을 직접 처리하는 것을 확인했어요. 참고로 Arista 문서도 MLAG 환경에서는 VRRP보다 VARP를 권장합니다. VRRP는 게이트웨이 MAC으로 오는 트래픽이 peer-link를 타고 master까지 가야 하지만, VARP는 두 스위치가 모두 직접 라우팅하기 때문이에요. 발견 2: MAC이 Po5가 아니라 Po10으로 학습된다 그림에서 vEOS47이 보낸 트래픽이 빨간 화살표를 따라 vEOS46을 거쳐 위쪽 vEOS로 올라간다고 해볼게요. 이때 vEOS46의 MAC 테이블에는 vEOS47의 MAC이 Eth1이 속한 channel group인 Po10 으로 잡힙니다. 여기까지는 당연합니다. MLAG는 MAC 테이블을 동기화합니다. 그러면 vEOS45는 vEOS47의 MAC을 어떻게 학습할까요? 저는 이 MAC이 vEOS46 쪽에 있으니 vEOS46으로 이어지는 Po5 로 학습할 거라고 예상했어요. 그런데 실제로 확인해보니 vEOS45도 vEOS47의 MAC을 Po10으로 학습 하고 있었습니다. 이유는 Po10이 두 장비에서 같은 MLAG 포트로 동작하기 때문이에요. vEOS47은 두 스위치에 모두 연결되어 있으니, vEOS45에도 vEOS47로 이어지는 로컬 Po10이 있습니다. MLAG가 동기화한 MAC은 상대 장비로 넘어가는 경로(peer-link)가 아니라 같은 MLAG 포트의 로컬 멤버 에 매핑돼요. Arista 문서에도 MLAG에서 개별 장비가 학습한 MAC은 동기화되어 적절한 인터페이스에 매핑된다고 나옵니다. 덕분에 vEOS47 앞으로 가는 트래픽이 vEOS45로 들어와도 peer-link를 거치지 않고 자기 쪽 Po10으로 바로 보낼 수 있어요. MLAG가 peer-link 사용을 최소화하도록 설계된 모습입니다. 알아두면 좋은 점 peer-link는 기본적으로 제어 통신이 중심이고, 한쪽 장비에만 연결된 단일 연결(single-homed) 장비가 있을 때 데이터 트래픽이 지나갑니다. MAC 테이블은 show mac address-table 로, MLAG 상태는 show mlag 로 확인합니다. 양쪽 장비의 MAC 테이블을 나란히 보면 같은 MAC이 어떤 포트로 학습됐는지 비교할 수 있어요. 정리 VRRP는 Active-Standby지만 Standby 스위치도 L2로 서버를 알고 있어서 하향 트래픽을 직접 처리할 수 있고, 라우팅이 필요한 상향 트래픽만 Primary를 거칩니다. MLAG가 동기화한 MAC은 peer-link가 아니라 같은 MLAG 포트(Po10)의 로컬 멤버로 학습되어, peer-link를 거치지 않고 트래픽을 보낼 수 있습니다.
What RADAR observed and classified to build this opportunity. It is what the source published, not a verification that the offer is still active.
[MLAG] MLAG + VRRP 환경의 트래픽 흐름. MLAG와 VRRP를 함께 쓰는 환경에서 트래픽이 어떻게 흐르는지, 벤더 교육 자료의 도식을 보고 EVE-NG에서 직접 구성해서 확인해봤습니다. 상향 트래픽은 자료와 같았는데 하향 트래픽은 실제 동작과 다르다고 판단했고, 실습하면서 MAC 테이블에서 재미있는 점도 하나 발견했어요. 먼저 구성 MLAG로 묶인 스위치 두 대(Primary, Secondary)가 있고, VRRP로 게이트웨이를 이중화합니다. VRRP는 Active-Standby로 동작하니 Primary가 게이트웨이 역할(master)을 맡아요. 위쪽에는 L3 장비가 두 스위치에 모두 연결되어 있고, 아래쪽 서버는 MLAG 포트로 두 스위치에 이중 연결됩니다. 트래픽 방향은 이렇게…
Open source