VRRP(Virtual Router Redundancy Protocol)는 게이트웨이 이중화 프로토콜입니다. active-standby로 동작하고, 목적은 fail over예요. 게이트웨이 장비 한 대가 죽어도 서버나 단말은 설정을 바꾸지 않고 계속 통신할 수 있습니다.
동작 방식
- 두 장비가 하나의 가상 IP(VIP)와 가상 MAC(vMAC)을 공유하고, 서버는 이 VIP를 게이트웨이로 씁니다.
- priority 값이 높은 장비가 master, 낮은 장비가 backup이 됩니다. 기본값은 100이에요.
- master는 1초마다 advertisement를 보내고, backup은 이게 끊기면 master가 죽었다고 보고 승격합니다.
- preempt를 켜두면, master가 죽어서 backup이 역할을 가져갔다가 원래 master가 살아났을 때 다시 역할을 되찾습니다. Arista에서는 기본으로 켜져 있어요.
슬라이드의 show 결과를 보면, master(priority 120)는 State is Master, backup(priority 100)은 State is Backup이고, backup의 Master Router에는 master의 주소(10.10.10.1)가 보입니다. VIP는 10.10.10.254, vMAC은 0000.5e00.010a예요. vMAC의 마지막 바이트 0a는 VRRP group 번호(10)를 16진수로 쓴 값입니다.
Master Down interval이 3.530s, 3.600s로 나오는 것도 눈여겨볼 만해요. Advertisement interval(1초)의 3배에 skew time을 더한 값이라, master가 사라지면 backup은 약 3.5초 뒤에 승격합니다.
fail over가 일어나 backup이 master로 승격하면, 그 장비는 GARP를 보내서 "이제 VIP와 vMAC을 가진 master는 나"라고 광고합니다.
실습 구성
EVE-NG에서 vEOS5를 master, vEOS6을 backup으로 구성했습니다. 아래쪽 vEOS가 두 장비에 연결되어 있고, 각 장비의 Eth3는 위쪽 업링크 장비로 이어집니다.
[master - vEOS5]
track UL interface Ethernet3 line-protocol
interface Vlan10
vrf BLUE
ip address 10.10.10.1/24
vrrp 10 priority-level 120
vrrp 10 preempt delay minimum 5 reload 30
vrrp 10 ipv4 10.10.10.254
vrrp 10 tracked-object UL decrement 30[backup - vEOS6]
interface Vlan10
vrf BLUE
ip address 10.10.10.2/24
vrrp 10 ipv4 10.10.10.254master 설정을 줄별로 보면 이렇습니다.
priority-level 120: 기본값(100)인 backup보다 높아서 master가 됩니다.preempt delay minimum 5 reload 30: preempt가 일어난 뒤 master 역할을 되찾기까지 5초를 기다리고(minimum), 재부팅한 경우에는 30초를 기다립니다(reload).tracked-object UL decrement 30: UL이라는 tracked object가 down이 되면 priority를 30 낮춥니다. UL은 Eth3(업링크)의 line protocol을 추적해요.
backup은 priority와 preempt를 기본값으로 둡니다. show vrrp brief 결과는 이렇습니다.
[master]
Interface VRF ID Ver Pri Time State Last Transition VR IP Addresses
Vl10 BLUE 10 2 120 3530 Master 00:11:43 ago 10.10.10.254
[backup]
Interface VRF ID Ver Pri Time State Last Transition VR IP Addresses
Vl10 BLUE 10 2 100 3600 Backup 00:02:36 ago 10.10.10.254실습: 업링크가 죽으면?
vEOS5의 업링크(Eth3)를 shutdown해봤습니다.
localhost(config-if-Et3)#shutdown
localhost(config-if-Et3)#sh vrrp vrf BLUE brief
Interface VRF ID Ver Pri Time State Last Transition VR IP Addresses
Vl10 BLUE 10 2 90 3640 Backup 00:00:02 ago 10.10.10.254tracked object UL이 down이 되면서 priority가 120에서 30만큼 줄어 90이 됐고, backup(100)보다 낮아져서 vEOS5는 Backup으로 내려갔습니다. show vrrp vrf BLUE all에서도 Priority is 90, Master Router is 10.10.10.2, priority is 100, Tracking object UL with priority 30 (Interfaces: Ethernet3)로 확인돼요.
새 master가 된 vEOS6에서는 priority 100으로 Master 상태가 됐고, 그 순간 GARP를 보냈습니다. vEOS6의 Eth1에서 캡처한 프레임입니다.
Frame 2: 60 bytes on wire (480 bits)
Ethernet II, Src: IETF-VRRP-VRID_0a (00:00:5e:00:01:0a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (reply/gratuitous ARP)출발지 MAC이 vMAC(00:00:5e:00:01:0a)이고 목적지는 브로드캐스트인 gratuitous ARP입니다. 이걸 받은 아래쪽 스위치가 vMAC의 위치를 vEOS6 쪽 포트로 새로 학습하기 때문에, 서버 트래픽이 새 master로 넘어갑니다.
알아두면 좋은 점
- tracking이 필요한 이유: 업링크가 죽어도 게이트웨이 장비 자체는 살아 있으면 VRRP advertisement가 계속 나가서 master를 유지합니다. 그러면 서버 트래픽이 나갈 길이 없는 장비로 향하죠. tracked object로 priority를 낮춰주면 이런 상황에서도 fail over가 일어납니다.
- decrement 값은
master priority − decrement가 backup priority보다 낮아야 의미가 있습니다. 이 실습은 120 − 30 = 90이 100보다 낮아서 전환이 됐어요. 값이 너무 작으면 업링크가 죽어도 master가 바뀌지 않습니다. - 복구하면 Eth3가 다시 올라오고 priority가 120으로 돌아옵니다. preempt가 켜져 있으니 minimum delay(5초) 뒤에 master 역할을 되찾습니다.
- MLAG 환경에서는 Arista가 VRRP보다 VARP를 권장합니다. VRRP는 게이트웨이 MAC으로 오는 트래픽이 peer-link를 타고 master까지 가야 하기 때문이에요.
정리
VRRP는 priority로 master와 backup을 정하고, preempt로 master의 복귀 여부를 정하며, tracked object로 업링크 장애까지 fail over에 반영할 수 있는 게이트웨이 이중화 프로토콜입니다. fail over가 일어나면 새 master가 vMAC으로 GARP를 보내 스위치의 MAC 테이블을 갱신하고, 서버는 같은 VIP로 계속 통신합니다.
