VRRP 이해

QFabric 시스템의 VRRP 차이점

기본 게이트웨이에 대한 정적 경로를 사용하여 네트워크에 서버를 구성하면 구성 노력과 복잡성을 최소화하고 처리 오버헤드를 줄일 수 있습니다. 그러나 기본 게이트웨이에 오류가 발생하면 일반적으로 치명적인 이벤트가 발생하여 서버가 격리됩니다. VRRP(Virtual Router Redundancy Protocol)를 사용하면 기본 게이트웨이에 장애가 발생할 경우 서버에 대체 게이트웨이를 동적으로 제공할 수 있습니다.

VRRP로 구성된 스위치는 서버에서 기본 경로로 구성하는 주소인 가상 IP(VIP) 주소를 공유합니다. 일반적인 VRRP 작동에서 스위치 중 하나는 VRRP 기본 스위치이며, 이는 VIP를 소유하고 활성 기본 게이트웨이임을 의미합니다. 다른 장치는 백업입니다. 스위치는 구성하는 우선 순위에 따라 기본 및 백업 역할을 동적으로 할당합니다. 기본 스위치에 장애가 발생하면 우선 순위가 가장 높은 백업 스위치가 기본 스위치가 되고 몇 초 내에 VIP의 소유권을 가져옵니다. 이 작업은 서버와의 상호 작용 없이 수행됩니다.

2개의 QFabric 시스템을 구성하여 마치 2개의 독립형 스위치인 것처럼 VRRP 구성에 참여할 수 있습니다. 그러나 일반적인 VRRP 작동에서는 한 번에 하나의 시스템만 지정된 VRRP 그룹의 기본 시스템이 될 수 있으며, 이는 그룹에 대해 구성된 VIP를 사용하여 하나의 시스템만 기본 게이트웨이 역할을 할 수 있음을 의미합니다. 두 개의 QFabric 시스템에서 VRRP를 실행할 때 두 시스템이 동시에 VIP를 사용하여 게이트웨이 역할을 하고 트래픽을 전달하기를 원할 수 있습니다. 이를 위해 방화벽 필터를 구성하여 두 네트워크 노드 그룹 간의 링크에서 QFabric 시스템 간의 VRRP 광고 패킷을 차단할 수 있습니다. 이렇게 하면 두 QFabric 시스템 모두 VIP가 수신한 기본 및 포워딩 트래픽(두 QFabric 시스템에 연결된 서버에서 구성하는 기본 게이트웨이 주소) 역할을 합니다. VMware의 vMotion을 사용하는 경우 이 구성을 사용하면 기본 게이트웨이 정보를 업데이트하지 않고도 QFabric 시스템에 연결된 서버 간에 가상 머신을 전환할 수 있습니다. 예를 들어, 데이터센터 A의 QFabric 시스템에 연결된 서버에서 실행 중인 가상 머신은 두 QFabric 시스템이 동일한 VIP를 사용하기 때문에 새로운 게이트웨이 IP 주소와 MAC 주소를 확인할 필요 없이 데이터센터 B의 QFabric 시스템에 연결된 서버로 전환할 수 있습니다.

구성 세부 정보

두 개의 QFabric 시스템에서 VRRP 그룹을 구성하는 것은 두 개의 스위치에서 VRRP를 구성하는 것과 유사합니다. 주요 차이점은 다음과 같습니다.

• VRRP에 참여하는 두 QFabric 시스템의 모든 인터페이스는 동일한 VLAN의 멤버여야 합니다.

• 두 QFabric 시스템의 해당 VLAN에 라우팅된 VLAN 인터페이스(RVI)를 생성해야 합니다.

• 두 RVI에 할당하는 IP 주소는 동일한 서브넷에 있어야 합니다.

• RVI에서 VRRP를 구성해야 합니다.

• 두 RVI 모두 동일한 VRRP 그룹의 멤버여야 합니다. 이를 통해 두 QFabric 시스템이 가상 IP 주소를 공유할 수 있습니다.

다음 표에는 두 개의 QFabric 시스템(QFabric 시스템 A 및 QFabric 시스템 B)에서 실행되는 VRRP 구성의 예가 나와 있습니다. 이 예는 두 QFabric 시스템이 VIP 10.1.1.50/24에 대한 VRRP 기본 역할을 하도록 구성되며 방화벽 필터가 시스템 간의 VRRP 광고를 차단한다고 가정합니다. 표 1 에는 예제 구성에서 RVI의 필수 특성이 나열되어 있습니다.

두 QFabric 시스템의 RVI에서 VRRP를 구성해야 합니다. 표 2 에는 각 RVI의 샘플 VRRP 구성 요소가 나열되어 있습니다. 우선 순위를 제외하고 매개변수는 두 시스템에서 동일 해야 합니다 .

표 3 에는 예제 구성에서 QFabric 시스템 A의 모든 인터페이스가 나열되어 있으며 이들이 무엇에 연결되는지 명시되어 있습니다.

표 4 에는 예제 구성에서 QFabric 시스템 B의 모든 인터페이스가 나열되어 있으며 이들이 무엇에 연결되는지 명시되어 있습니다.

Junos OS VRRP 지원

릴리스 12.2 이전 릴리스에서 Junos OS는 RFC 3768, VRRP(Virtual Router Redundancy Protocol)( IPv4용) 및 인터넷 초안 draft-ietf-vrrp-ipv6-spec-08, IPv6용 가상 라우터 이중화 프로토콜을 지원했습니다.

VRRPv3는 Junos OS 릴리스 12.2 이전 릴리스를 사용하는 라우터에서 지원되지 않으며 QFX10000 스위치의 IPv6에도 지원되지 않습니다.

릴리스 12.2부터 Junos OS는 다음을 지원합니다.

• RFC 3768, 가상 라우터 이중화 프로토콜(VRRP)

• RFC 5798, IPv4 및 IPv6용 VRRP(Virtual Router Redundancy Protocol) 버전 3

• RFC 6527, 가상 라우터 중복 프로토콜 버전 3(VRRPv3)에 대한 매니지드 객체의 정의

IPv6 VRRP 체크섬 동작 차이

IPv6 VRRP 네트워크를 활성화할 때 다음과 같은 체크섬 차이를 고려해야 합니다.

• Junos OS 릴리스 12.2 이전 릴리스에서 IPv6용 VRRP가 구성된 경우 VRRP 체크섬은 RFC 3768, VRRP(Virtual Router Redundancy Protocol)의 섹션 5.3.8에 따라 계산됩니다.

• Junos OS 릴리스 12.2부터 IPv6용 VRRP가 구성되면 VRRPv3의 활성화 여부와 관계없이 VRRP 체크섬은 RFC 5798의 섹션 5.2.8, IPv4 및 IPv6용 VRRP(Virtual Router Redundancy Protocol) 버전 3에 따라 계산됩니다.

  또한 의사 헤더는 IPv6 VRRP 체크섬을 계산할 때만 포함됩니다. IPv4 VRRP 체크섬을 계산할 때 의사 헤더는 포함되지 않습니다.

  Junos OS 릴리스 12.2(또는 이후 Junos OS 릴리스)가 있는 라우터가 IPv6 VRRP가 릴리스 12.2 이전의 Junos OS 릴리스를 실행하는 라우터와 상호 운용되도록 하려면 Junos OS 릴리스 12.2 이상을 실행하는 라우터의 계층 수준에서 구성 문을 [edit protocols vrrp] 포함합니다checksum-without-pseudoheader.

• Junos OS 릴리스 12.2 이상의 유틸리티는 tcpdump RFC 5798, IPv4 및 IPv6용 VRRP(Virtual Router Redundancy Protocol) 버전 3에 따라 VRRP 체크섬을 계산합니다. 따라서 이전 Junos OS 릴리스(Junos OS 릴리스 12.2 이전)bad vrrp cksum에서 수신된 IPv6 VRRP 패킷을 구문 분석할 때 tcpdump 메시지가 표시됩니다.

  이 메시지는 VRRP 실패를 나타내지 않으므로 무시해도 됩니다.

VRRP 상호 운용성

Junos OS 릴리스 12.2 이전 릴리스에서 VRRP(IPv6)는 인터넷 초안 draft-ietf-vrrp-ipv6-spec-08을 따랐지만, 체크섬은 RFC 3768 섹션 5.3.8을 기반으로 계산되었습니다. 릴리스 12.2부터 VRRP(IPv6)는 RFC 5798을 따르며 체크섬은 RFC 5798 섹션 5.2.8에 따라 계산됩니다. VRRP 체크섬 계산의 차이로 인해 Junos OS 릴리스 12.2 이상 릴리스를 사용하는 라우터에서 구성된 IPv6 VRRP는 Junos OS 릴리스 12.2 이전 릴리스에서 구성된 IPv6 VRRP와 상호 운용되지 않습니다.

Junos OS 릴리스 12.2(또는 이후 Junos OS 릴리스)가 있는 라우터가 릴리스 12.2 이전의 Junos OS 릴리스를 실행하는 라우터와 IPv6 VRRP가 상호 운용되도록 하려면 Junos OS 릴리스 12.2 이상이 설치된 라우터의 계층 수준에서 구성 문을 [edit protocols vrrp] 포함합니다checksum-without-pseudoheader.

VRRP 상호 운용성에 대해 알아야 할 몇 가지 일반적인 사항은 다음과 같습니다.

• Junos OS 릴리스 12.2 이상 릴리스를 사용하는 라우터에서 VRRPv3(IPv4 또는 IPv6)를 구성한 경우 Junos OS 릴리스 12.1 또는 이전 릴리스를 사용하는 라우터에서는 작동하지 않습니다. 이는 Junos OS 릴리스 12.2 이상 릴리스만 VRRPv3를 지원하기 때문입니다.

• Junos OS 릴리스 12.2 이상 릴리스를 사용하는 라우터에서 구성된 VRRP(IPv4 또는 IPv6)는 Junos OS 릴리스 12.2 이전 릴리스를 사용하는 라우터에서 구성된 VRRP(IPv4 또는 IPv6)와 상호 운용됩니다.

• IPv4용 VRRPv3는 이전 버전의 VRRP와 상호 운용되지 않습니다. VRRPv2 IPv4 광고 패킷이 VRRPv3이 활성화된 라우터에 의해 수신되면, 라우터는 네트워크에서 여러 프라이머리가 생성되지 않도록 백업 상태로 전환됩니다. 이러한 동작으로 인해 기존 VRRPv2 네트워크에서 VRRPv3를 활성화할 때 주의해야 합니다. 자세한 내용은 VRRPv2 에서 VRRPv3로 업그레이드를 참조하십시오.

  참고:

  VRRPv3 광고 패킷은 이전 버전의 VRRP가 구성된 라우터에서 무시됩니다.

VRRPv2에서 VRRPv3으로 업그레이드

네트워크의 모든 VRRP 라우터에서 VRRPv3를 활성화할 수 있는 경우에만 네트워크에서 VRRPv3를 활성화합니다.

VRRPv2에서 VRRPv3으로 업그레이드할 때만 VRRPv2 네트워크에서 VRRPv3를 활성화합니다. 두 버전의 VRRP를 혼합하는 것은 영구적인 해결책이 아닙니다.

VRRPv2에서 VRRPv3로의 업그레이드는 다음과 같은 고려 사항으로 인해 트래픽 손실을 방지하기 위해 매우 신중하게 수행해야 합니다.

• 모든 라우터에서 VRRPv3를 동시에 구성할 수는 없습니다.

• 전환 기간 동안 VRRPv2와 VRRPv3는 모두 네트워크에서 작동합니다.

• VRRP 버전을 변경하면 모든 VRRP 그룹의 상태 시스템이 다시 시작됩니다.

• VRRPv3(IPv4용) 라우터는 VRRPv2(IPv4용) 광고 패킷을 받을 때 기본적으로 백업 상태로 설정됩니다.

• VRRPv2(IPv4용) 패킷에는 항상 가장 높은 우선 순위가 부여됩니다.

• VRRPv2와 VRRPv3(IPv6용) 간의 체크섬 차이로 인해 여러 기본 라우터가 생성될 수 있습니다.

  업그레이드하는 동안 백업 라우터에서 VRRPv3(IPv6용)를 비활성화하여 여러 기본 라우터가 생성되지 않도록 합니다.

표 5 에는 VRRPv2에서 VRRPv3으로 전환하는 동안 발생하는 단계와 이벤트가 설명되어 있습니다. 표 5에서 두 개의 VRRPv2 라우터인 R1과 R2는 G1과 G2의 두 그룹으로 구성되어 있습니다. 라우터 R1은 G1의 기본 역할을 하고 라우터 R2는 G2의 기본 역할을 합니다.

VRRPv3를 활성화할 때 VRRPv3(IPv4)는 이전 버전의 VRRP와 상호 운용되지 않으므로 네트워크의 모든 VRRP 라우터에서 VRRPv3가 활성화되어 있는지 확인하십시오. 예를 들어, VRRPv2 IPv4 광고 패킷이 VRRPv3이 활성화된 라우터에 의해 수신되는 경우, 라우터는 네트워크에서 여러 프라이머리가 생성되지 않도록 백업 상태로 전환됩니다.

계층 수준(IPv4 또는 IPv6 네트워크의 경우)에서 version-3 문을 구성하여 VRRPv3를 [edit protocols vrrp] 활성화할 수 있습니다. LAN의 모든 VRRP 라우터에서 동일한 프로토콜 버전을 구성합니다.

VRRPv3 기능의 기능

일부 Junos OS 기능은 VRRPv3에서 이전 VRRP 버전과 다릅니다.

• VRRPv3 인증
• VRRPv3 광고 간격
• VRRPv3용 통합 ISSU

failover-delay가 구성되지 않은 경우

페일오버 지연이 구성되지 않은 경우, 라우팅 엔진에서 운영되는 VRRP 세션의 이벤트 순서는 다음과 같습니다.

1. 라우팅 엔진에서 탐지한 첫 번째 VRRP 그룹의 상태가 변경되고 새로운 상태가 기본이 되면 라우팅 엔진은 적절한 VRRP 공지 메시지를 생성합니다. 패킷 전달 엔진에 상태 변경에 대한 정보가 제공되므로 해당 그룹에 대한 하드웨어 필터가 지연 없이 다시 프로그래밍됩니다. 그런 다음 새 기본은 VRRP 그룹에 Gratuitous ARP 메시지를 보냅니다.

2. 페일오버 타이머의 지연이 시작됩니다. 기본적으로 장애 조치-지연 타이머는 다음과 같습니다.

   • 500밀리초 - 구성된 VRRP 알림 간격이 1초 미만인 경우.

   • 2초 - 구성된 VRRP 알림 간격이 1초 이상이고 라우터의 총 VRRP 그룹 수가 255개인 경우.

   • 10초 - 구성된 VRRP 알림 간격이 1초 이상이고 라우터의 VRRP 그룹 수가 255개 이상인 경우.

3. 라우팅 엔진은 후속 VRRP 그룹에 대해 하나씩 상태 변경을 수행합니다. 상태가 변경될 때마다 특정 VRRP 그룹의 새로운 상태가 기본이 되면 라우팅 엔진은 적절한 VRRP 공지 메시지를 생성합니다. 그러나 패킷 전달 엔진에 대한 통신은 장애 조치 지연 타이머가 만료될 때까지 억제됩니다.

4. 페일오버 지연 타이머가 만료된 후 라우팅 엔진은 상태를 변경한 모든 VRRP 그룹에 대한 메시지를 패킷 전달 엔진으로 보냅니다. 결과적으로 해당 그룹에 대한 하드웨어 필터가 다시 프로그래밍되고 새 상태가 기본인 그룹에 대해 Gratuitous ARP 메시지가 전송됩니다.

이 프로세스는 모든 VRRP 그룹에 대한 상태 전환이 완료될 때까지 반복됩니다.

따라서 페일오버 지연을 구성하지 않으면 첫 번째 VRRP 그룹에 대한 전체 상태 전환(라우팅 엔진 및 패킷 전달 엔진의 상태 포함)이 즉시 수행되는 반면, 나머지 VRRP 그룹에 대한 패킷 전달 엔진의 상태 전환은 구성된 VRRP 공지 타이머 및 VRRP 그룹 수에 따라 최소 0.5-10초 지연됩니다. 이 중간 상태 동안, 패킷 전달 엔진에서 아직 완료되지 않은 상태 변경에 대한 VRRP 그룹의 수신 트래픽은 하드웨어 필터의 지연된 재구성으로 인해 패킷 전달 엔진 수준에서 손실될 수 있습니다.

failover-delay가 구성된 경우

페일오버 지연이 구성되면 라우팅 엔진에서 운영되는 VRRP 세션의 이벤트 시퀀스가 다음과 같이 수정됩니다.

1. 라우팅 엔진은 일부 VRRP 그룹에 상태 변경이 필요함을 감지합니다.

2. 페일오버 지연은 구성된 기간 동안 시작됩니다. 허용되는 장애 조치(failover) 지연 타이머 범위는 50밀리초에서 100,000밀리초까지입니다.

3. 라우팅 엔진은 VRRP 그룹에 대해 하나씩 상태 변경을 수행합니다. 상태가 변경될 때마다 특정 VRRP 그룹의 새로운 상태가 기본이 되면 라우팅 엔진은 적절한 VRRP 공지 메시지를 생성합니다. 그러나 패킷 전달 엔진에 대한 통신은 장애 조치 지연 타이머가 만료될 때까지 억제됩니다.

4. 페일오버 지연 타이머가 만료된 후 라우팅 엔진은 상태를 변경한 모든 VRRP 그룹에 대한 메시지를 패킷 전달 엔진으로 보냅니다. 결과적으로 해당 그룹에 대한 하드웨어 필터가 다시 프로그래밍되고 새 상태가 기본인 그룹에 대해 Gratuitous ARP 메시지가 전송됩니다.

이 프로세스는 모든 VRRP 그룹에 대한 상태 전환이 완료될 때까지 반복됩니다.

따라서 페일오버 지연이 구성되면 첫 번째 VRRP 그룹에 대한 패킷 전달 엔진 상태도 지연됩니다. 그러나 네트워크 운영자는 VRRP 상태 변경 중 중단을 최소화하기 위해 네트워크 구축의 요구에 가장 적합한 페일오버 지연 값을 구성할 수 있는 이점이 있습니다.

failover-delay는 라우팅 엔진에서 실행되는 VRRP 프로세스(vrrpd)에 의해 운영되는 VRRP 세션에만 영향을 미칩니다. 패킷 전달 엔진에 배포된 VRRP 세션의 경우, 페일오버 지연 구성은 효과가 없습니다.