[ACP-DC 교육#10] VSX (2) - 루바루바의 엣지있는 네트워크 이야기

지난 글에서는 HPE Aruba Networking AOS-CX 스위치의 가상화 기술인 VSX에 대해 알아보았습니다.

VSX의 구성요소와 VSF와의 차이점, 장점 등을 설명했는데요. 오늘은 실용적인 부분들을 다뤄볼까 합니다.
실제 VSX를 활용해서 소프트웨어 라이브 업그레이드 방법이라든가 Split brain과 같은 기술을 살펴보겠습니다.

VSX 컨트롤 플레인 분리 및 소프트웨어 업데이트

컨트롤 플레인 분리

위 그림에서 왼쪽의 물리적 토폴로지는 코어 스위치와 애그리게이션 스위치 VSX 쌍 사이에 L2 MC-LAG를 사용하여 각 코어와 VSX 쌍 사이에 OSPF 브로드캐스트 도메인을 생성하는 예시입니다. 이는 각 스위치가 서로 다른 라우팅 정보를 가지고 독립적으로 작동하는, 논리적으로 분리된 컨트롤 플레인(오른쪽 그림)을 보여줍니다.

VSX 소프트웨어 업데이트 명령

단일 명령어를 사용한 자동 업그레이드 조율

switch# vsx update-software tftp://15.136.40.99/XL_10_02_0001BM.swi vrf mgmt.
Do you want to save the current configuration (y/n)? y
The running configuration was saved to the startup configuration.
This command will download new software to the primary image of both VSX primary and
secondary systems, then reboot them in sequence. The VSX secondary will reboot first,
followed by primary. 
Continue (y/n)? y
VSX Primary Software Update Status   : Reboot started
VSX Secondary Software Update Status : Image updated successfully
VSX ISL Status                       : Down
Progress [####################################################################################.]
Secondary VSX system updated completely. Rebooting primary.

vsx update-software <REMOTE-URL> [vrf <VRF-NAME>]
위 명령은 메인(Primary) 노드에서 실행되며, 다음 작업을 수행합니다.

소프트웨어 다운로드:

TFTP 서버에서 새로운 소프트웨어를 다운로드합니다.

검증 및 설치:

다운로드 및 검증이 성공적으로 완료되면, Primary(메인)와 Secondary(백업)시스템의 대체 이미지에 소프트웨어를 설치합니다.

순차적 재부팅:

다운로드 후 다음 순서로 재부팅을 진행합니다.

먼저 Secondary 스위치에 재부팅 알림을 보냅니다.
Secondary 스위치가 안정적인 상태로 돌아올 때까지 모니터링합니다.
그 후 Primary 스위치를 재부팅합니다.

만약 Secondary 스위치가 재부팅에 실패하는 경우, Primary 스위치는 펌웨어 업데이트 작업을 중단하고 계속 활성 상태를 유지합니다.
만약 스위치가 Primary 이미지로 부팅되었다면, 소프트웨어는 세컨더리 이미지에 설치됩니다.

Secondary VSX가 재부팅되는 동안 Primary는 트래픽을 활발히 포워딩합니다.
Primary가 재부팅되기 전에는 Secondary가 이미 정상 작동하며 트래픽을 포워딩합니다.

업그레이드 프로세스 오케스트레이션

자동 업그레이드 프로세스가 시작되면:

Step 0 – 소프트웨어 다운로드

두 스위치 모두에 소프트웨어를 다운로드합니다.

switch-1# vsx update-software tftp://15.136.40.99/XL_10_02_0001BM.swi vrf mgmt
Do you want to save the current configuration (y/n)? y
The running configuration was saved to the startup configuration.
This command will download new software to the primary image of both VSX primary and
secondary systems, then reboot them in sequence. The VSX secondary will reboot first,
followed by primary.
Continue (y/n)? y
VSX Primary Software Update Status   : Image download started 
VSX Secondary Software Update Status : Image download started
VSX ISL Status : Up
Progress [#############################................................................]

Step 1 – Secondary 스위치 재부팅

다운로드가 완료되면 Secondary 스위치가 먼저 재부팅합니다.
이로 인해 모든 트래픽은 Failover된 Primary 스위치로 전달됩니다.

VSX Primary Software Update Status   : Waiting for VSX secondary to reboot complete 
VSX Secondary Software Update Status : Rebooting
VSX ISL Status                       : Down
Progress [#############################................................................]

Step 2 – Primary 스위치 대기

Secondary 스위치가 새로운 버전으로 부팅되면, Primary 스위치는 링크-업 지연 타이머가 만료될 때까지 기다립니다.
이는 Secondary 스위치가 트래픽 관리에 필요한 모든 엔트리를 확보했는지 확인하기 위함입니다.

VSX Primary Software Update Status : Waiting for VSX to complete 
VSX Secondary Software Update Status : Image updated successfully
VSX ISL Status : Up
Progress [#############################................................................] 

switch-02# sh vsx status linkup-delay
Initial sync status    : Completed
Delay timer status     : Running
Linkup Delay time left : 2 minutes 22 seconds

switch-02# sh vsx status linkup-delay 
Initial sync status    : Completed 
Delay timer status     : Completed
Linkup Delay time left :

Step 3 – Primary 스위치 재부팅

이후 Primary 스위치가 스스로 재부팅하여 모든 트래픽을 Secondary 스위치로 전달합니다.

VSX Primary Software Update Status   : Waiting for VSX to complete 
VSX Secondary Software Update Status : Image updated successfully
VSX ISL Status                       : Down
Progress [#############################................................................] 

Second VSX system updated completely. Rebooting primary.

Step 4 – Primary 복귀

Primary가 새로운 버전으로 재부팅되면, Secondary 스위치로부터 모든 엔트리(경로, MAC 주소, ARP 등)를 다운로드받습니다.
링크-업 타이머가 만료된 후, 트래픽은 두 스위치 간에 균형 있게 분산됩니다.

switch-1# sh vsx status linkup-delay
Configured linkup delay-timer : 180 seconds 
Initial sync status           : Completed Delay 
timer status                  : Running
Linkup Delay time left        : 1 minutes 58 seconds 

switch-1# sh vsx status linkup-delay
Configured linkup delay-timer : 180 seconds
Initial sync status           : Completed 
Delay timer status            : Running
Linkup Delay time left        :

코어 레이어의 VSX: 단순화 및 최적화 전략

일반적으로 VSX는 어그리게이션 레이어에 배포되지만, 특정 환경에서는 코어 레이어에 VSX를 구현하는 것이 유리할 수 있습니다.

어그리게이션 레이어가 L2로만 작동하는 경우

스패닝 트리 제거: 어그리게이션 레이어가 오직 L2로만 작동할 때, VSX는 코어 레이어에서 VSX LAG를 통해 스패닝 트리의 필요성을 없애는 데 도움을 줍니다.
액티브-액티브 게이트웨이: VSX는 코어 스위치가 액세스 VLAN에 대해 액티브-액티브 디폴트 게이트웨이 서비스를 제공할 수 있도록 합니다.
토폴로지 단순화: 이러한 접근 방식은 토폴로지를 단순화합니다. 트래픽은 레이어 2로 코어까지 흐른 다음, 코어에서 모든 트래픽을 라우팅합니다. 더 단순한 토폴로지는 페일오버 시간을 단축시킬 수 있습니다.

그 밖에도 아래와 같은 특정 상황에서 HPE는 코어 스위치에 VSX를 사용할 것을 권장합니다.

네트워크가 IPv6를 사용하고 많은 VRF(Virtual Routing and Forwarding)를 지원해야 하는 경우
라우팅 프로토콜로 OSPF를 사용하여 OSPF 성능을 최적화해야 할 경우

VSX의 이점:

각 VRF는 각 VSX LAG에 자체 트랜짓 VLAN(transit VLAN)과 연관된 SVI(Switch Virtual Interface)가 필요합니다.
이 때, 코어 스위치를 VSX 쌍으로 결합함으로써, VSX LAG의 수가 절반으로 줄어듭니다.
이는 트랜짓 VLAN과 SVI의 수도 절반으로 줄여줍니다.

트랜짓 VLAN과 SVI의 수가 줄어들면 SPF(Shortest Path First) 계산의 부담을 최소화하고 단순화할 수 있습니다.

코어 레이어의 VSX: 빠른 컨버전스 또는 무(無) 컨버전스

코어 레이어에 VSX를 사용하는 또 다른 이유는 코어와 어그리게이션 레이어 간의 링크 실패 시, 빠른 컨버전스(Convergence) 또는 컨버전스가 전혀 필요 없다는 점입니다. 특히 업링크를 적게 사용했을 때 이러한 장점이 두드러집니다.

독립적인 코어 스위치 vs. VSX 코어 스위치

위 그림의 오른쪽을 살펴보면, 두 개의 독립적인 스위치가 코어 레이어로 작동하는 레거시 상황을 보여줍니다.

Core-1과 Aggregation-1 사이의 링크에 장애가 발생하면, Core-1은 대체 경로를 찾기 위해 라우팅 테이블을 업데이트해야 합니다.
이 새로운 경로는 스위치의 FIB(Forwarding Information Base)에 로드되어야 합니다. 이는 시간이 소요되는 과정입니다.

결국 이러한 컨버전스 과정 때문에 지연이 발생할 수 밖에 없습니다.

하지만, 그림 왼쪽은 코어와 어그리게이션 레이어 모두 VSX를 실행하는 시나리오를 보여줍니다.

장점: Core-1과 Aggregation-1 사이의 업링크 하나에 장애가 발생하더라도 컨버전스가 필요 없습니다.
이유: VSX LAG를 통해 두 스위치가 하나의 논리적 장치처럼 작동하기 때문에, 다음 홉(next hop)은 여전히 동일합니다. 따라서 라우팅 테이블을 업데이트할 필요가 없습니다.

즉, 링크 장애시 컨버전스 과정 없이 장애 복구 시간을 획기적으로 단축시켜 서비스의 연속성을 보장하는 큰 이점을 제공합니다.

IPv6와 VSX 액티브 포워딩: SVI 제한의 이유

IPv6 환경에서 VSX 액티브 포워딩을 사용할 때 한 가지 중요한 제약 사항이 있습니다.

VRF당 단 하나의 SVI만 액티브 포워딩을 지원할 수 있습니다.
이는 각 SVI의 링크-로컬 주소(link-local address)가 동일하기 때문입니다.

액티브 포워딩과 IPv6의 상호작용

피어 MAC 주소 프로그래밍: 액티브 포워딩이 활성화되면, 각 스위치는 피어 스위치의 MAC 주소를 자신의 라우터 MAC 주소로 인식하도록 프로그래밍합니다.
라우팅 vs. 브리징: 그 결과, 스위치가 피어의 IP 주소(및 피어의 MAC 주소)를 목적지로 하는 패킷을 받으면, 전통적인 방식처럼 브리징(bridging)하는 대신 하드웨어(HW)에서 해당 프레임을 피어에게 “라우팅”하게 됩니다. 이 과정은 두 스위치가 동일한 IP 서브넷/VLAN에 있더라도 마찬가지입니다.
IPv6 링크-로컬 주소: 마찬가지로, VSX 스위치 B에 도착한 트래픽의 목적지가 VSX 스위치 A의 링크-로컬 주소일 경우, 스위치 B는 이 트래픽을 ISL을 통해 스위치 A로 “라우팅”합니다.

VRF당 단일 SVI로 제한되는 이유

이러한 작동 방식 때문에 다음과 같은 문제가 발생합니다:

링크-로컬 주소 중복: 동일한 VRF 내에 여러 SVI가 있고 이들이 동일한 링크-로컬 주소를 가질 경우, 하드웨어의 라우팅 테이블은 여러 SVI의 링크-로컬 주소를 모두 받아들여 포워딩을 위해 프로그래밍할 수 없습니다.
하나만 인식: 하드웨어는 여러 개의 중복된 링크-로컬 주소 중 단 하나만 인식하고 포워딩을 위해 프로그래밍할 수 있습니다. 나머지 주소들은 중복으로 처리됩니다.

따라서, IPv6를 사용할 때는 액티브 포워딩을 VRF당 하나의 SVI에만 활성화해야 합니다.
이를 통해 하드웨어의 라우팅 테이블이 혼동 없이 올바르게 작동하고 트래픽이 예상대로 라우팅될 수 있습니다.

스플릿 브레인 (Split-brain): VSX의 장애 시나리오 및 보호 메커니즘

스플릿 브레인 시나리오

아래 그림은 두 VSX 스위치 간의 ISL(Inter-Switch Link)이 다운된 상황을 보여줍니다.

두 스위치 자체는 여전히 살아 있는 상태이지만, 서로 정보를 교환할 수 없어 동기화가 끊어집니다.
이러한 상황을 “스플릿 브레인(Split-brain)”이라고 하며, 킵얼라이브(keepalive) 기능이 활성화되지 않았을 때 발생합니다.

킵얼라이브는 VSX 스위치 간의 링크가 다운되었는지 또는 VSX 스위치 자체가 작동하지 않는지를 감지하는 아웃-오브-밴드(out-of-band) 메커니즘을 제공하여 스플릿 브레인 문제를 방지합니다. 킵얼라이브 기능이 작동하면 Agg2와 액세스 스위치 간의 링크를 다운시켜, 트래픽이 액세스 스위치에서 Agg1로만 흐르도록 강제합니다.

ISL 및 킵얼라이브 상태에 따른 동작

ISL 상태	KeepAlive 상태	결과
Up (In-Sync)	Established	정상 작동. 트래픽이 정상적으로 포워딩되고 시스템은 스플릿 브레인으로부터 보호됩니다.
Up (In-Sync)	Not established (Init	정상 작동하지만, 시스템이 스플릿 브레인 위험에 노출됩니다. ISL 장애 시 보호 메커니즘이 없습니다.
Down (Out-of-Sync)	Established	스플릿 브레인 방지. 피어들이 서로 아직 살아 있음을 인지합니다. 세컨더리 스위치는 자신의 VSX LAG를 셧다운하여 트래픽이 프라이머리로만 흐르도록 합니다.
Down (Out-of-Sync)	Not established	스위치는 피어가 다운되었다고 가정합니다. 시스템은 기능하지만 50% 용량으로만 트래픽을 포워딩합니다. 이 가정이 정확하려면 킵얼라이브 연결이 올바르게 구성되어야 합니다.

ISL 장애 시 동작

VSX LAG가 아닌 포트:

VSX LAG에 속하지 않지만 최소 하나 이상의 Orphan 포트¹(ISL LAG 제외)에 속한 VLAN 및 관련 SVI는 ISL 장애 시 상태(up/down)에 영향을 받지 않습니다.

최초 동기화 전 ISL 장애 발생시:

세컨더리 VSX 노드에 VSX LAG의 멤버인 포트가 있는 한, 해당 VSX LAG에 의해 전송되는 VLAN의 관련 SVI는 Orphan 포트가 있든 없든 VSX 세컨더리 노드에서 OFF/SHUT(비활성화/셧다운) 상태가 됩니다.

최초 동기화 이후 링크-업 지연 타이머(Link-up Delay Timer) 동안:

Secondary VSX 스위치의 VSX LAG에 속한 포트가 있는 한, 해당 VSX LAG가 전달하는 VLAN의 SVI는 무조건 비활성(OFF/SHUT) 상태를 유지합니다. 이 규칙은 그 VLAN에 연결된 ‘Orphan 포트’가 있든 없든 상관없게 됩니다.

하지만 딱 두 가지 조건을 모두 만족하면, 이 SVI가 다시 활성화(ON/UP)될 수 있습니다.

VSX LAG가 제외 그룹에 포함: linkup-delay-timer exclude lag-list 명령어로 해당 VSX LAG를 ‘지연 타이머’에서 제외되어야 합니다.
해당 VLAN이 제외 그룹 밖의 VSX LAG에서는 비허용: 이 VLAN은 오직 ‘제외 그룹’에 속한 VSX LAG를 통해서만 트래픽이 허용되어야 합니다.

이 복잡한 규칙은 재부팅된 스위치가 아직 완전히 준비되지 않았을 때, 모든 트래픽이 이미 안정화된 다른 스위치(Primary)로만 흐르도록 강제해서 트래픽 손실을 막는 안전장치로 보면 됩니다.

위 그림 예시를 보면, ISL이 고장 났을 때, 스위치들은 다음과 같이 작동해요.

VSX LAG 관련 포트/SVI: 자동으로 비활성화. 이는 스플릿 브레인 상황을 막기 위함입니다.
ISL이 끊어진 상태에서 양쪽 스위치가 모두 트래픽을 처리하려고 하면, 데이터가 꼬이거나 루프가 발생할 수 있기 때문
VSX LAG와 관련 없는 포트/SVI (Orphan 포트): 계속 정상적으로 작동.
위의 Server-2와 VLAN 20은 계속 켜져 있지만, 외부 업링크가 없으면 이 서버는 외부 네트워크와 통신할 수 없어 고립
SVI 비활성화 예시: Server-3의 포트는 여전히 ‘활성(UP)’ 상태지만, 해당 포트가 속한 VLAN 10의 SVI는 ISL 장애 때문에 ‘비활성(SHUT)’ 상태가 됩니다. 이는 해당 VLAN이 VSX LAG에 속하기 때문

결론적으로, 데이터센터에서는 항상 이중화된 연결을 계획하는 것이 가장 중요합니다.
그래야 ISL이나 스위치에 장애가 생겼을 때도 서비스가 중단되지 않게 됩니다.

스플릿 복구 (Split Recovery)

목적: 스플릿 복구 모드는 ISL이 동기화 상태가 아닐 때 킵얼라이브마저 실패하면, Secondary 스위치가 자신의 VSX LAG를 활성화하도록 보장합니다.
기본 동작: ISL의 동기화가 끊어지고 킵얼라이브가 작동하면, 네트워크는 Secondary VSX LAG와 SVI를 다운시킵니다.
문제점: 만약 킵얼라이브가 실패하고 기본적으로 활성화되어 있는 스플릿 복구 모드가 작동하면, Secondary 스위치는 자신의 VSX LAG와 SVI를 다시 활성화합니다.
이 경우, Primary 스위치가 살아있는 상황에서 비대칭 트래픽 흐름으로 인해 스플릿 브레인이 발생하고 트래픽 손실로 이어질 수 있습니다.
해결책: 이러한 상황을 피하기 위해 스플릿 복구 모드를 비활성화하는 것이 좋습니다.

이렇게 VSX와 관련하여 알아보았습니다.

현대의 데이터센터는 비즈니스 연속성과 관련하여 고가용성, 탄력성 등이 매우 중요해지고 있습니다.
단순히 링크 이중화와 같은 기술을 넘어 더 혁신적이고 가용성을 높이는 방법이 필요합니다.

VSX는 라이브 업그레이드를 통해 무중단 업데이트를 가능하게 하고, 킵얼라이브를 통해 스플릿 브레인을 방지합니다.
AOS-CX 스위치만이 갖고 있는 VSX 기능을 통해 데이터센터 무중단 서비스를 유지하세요.

VSX LAG(Link Aggregation Group)에 포함되지 않고 단일 VSX 스위치에 연결된 다운스트림 포트 ↩︎