VRRP 이해

QFabric 시스템의 VRRP 차이점

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

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

두 개의 QFabric 시스템을 구성하여 마치 두 개의 독립형 스위치인 것처럼 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용 Virtual Router Redundancy Protocol을 지원했습니다.

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

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

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

• RFC 5798, IPv4 및 IPv6을 위한 가상 라우터 중복 프로토콜(VRRP) 버전 3

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

IPv6 VRRP 체크섬 동작 차이

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

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

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

  또한 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 체크섬을 계산합니다. tcpdump 따라서 이전 Junos OS 릴리스(Junos OS 릴리스 12.2 이전) bad vrrp cksum 에서 수신한 IPv6 VRRP 패킷을 구문 분석하면 메시지가 표시됩니다.

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

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와 상호 운용되지 않습니다. VRRPv3가 활성화된 라우터에서 VRRPv2 IPv4 광고 패킷을 수신하면 라우터는 네트워크에서 여러 프라이머리가 생성되지 않도록 스스로 백업 상태로 전환됩니다. 이 동작으로 인해 기존 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가 활성화되어 있는지 확인합니다. 예를 들어 VRRPv3가 활성화된 라우터에서 VRRPv2 IPv4 광고 패킷을 수신하면 라우터는 네트워크에서 여러 프라이머리가 생성되지 않도록 스스로 백업 상태로 전환됩니다.

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

VRRPv3 기능의 기능

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

• VRRPv3 인증
• VRRPv3 광고 간격
• VRRPv3를 위한 통합 ISSU

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

페일오버 지연을 구성하지 않은 경우, 라우팅 엔진에서 작동하는 VRRP 세션의 이벤트 시퀀스는 다음과 같습니다:

1. 라우팅 엔진이 감지한 첫 번째 VRRP 그룹이 상태를 변경하고 새로운 상태가 기본이면 라우팅 엔진은 적절한 VRRP 알림 메시지를 생성합니다. 패킷 포워딩 엔진은 상태 변경에 대한 정보를 제공받아 해당 그룹에 대한 하드웨어 필터가 지체 없이 다시 프로그래밍됩니다. 그러면 새로운 기본은 VRRP 그룹에 Gratuitous ARP 메시지를 보냅니다.

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

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

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

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

3. 라우팅 엔진은 후속 VRRP 그룹에 대해 하나씩 상태 변경을 수행합니다. 상태 변경이 있을 때마다 특정 VRRP 그룹의 새로운 상태가 기본인 경우 라우팅 엔진은 적절한 VRRP 알림 메시지를 생성합니다. 그러나 패킷 포워딩 엔진으로의 통신은 페일오버 지연 타이머가 만료될 때까지 억제됩니다.

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

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

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

failover-delay가 구성된 경우

failover-delay가 구성되면 라우팅 엔진에서 작동하는 VRRP 세션의 이벤트 시퀀스가 다음과 같이 수정됩니다.

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

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

3. 라우팅 엔진은 VRRP 그룹에 대해 하나씩 상태 변경을 수행합니다. 상태 변경이 있을 때마다 특정 VRRP 그룹의 새로운 상태가 기본인 경우 라우팅 엔진은 적절한 VRRP 알림 메시지를 생성합니다. 그러나 패킷 포워딩 엔진으로의 통신은 페일오버 지연 타이머가 만료될 때까지 억제됩니다.

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

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

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

failover-delay는 라우팅 엔진에서 실행되는 VRRP 프로세스(vrrpd)에 의해 운영되는 VRRP 세션에만 영향을 미칩니다. 패킷 포워딩 엔진에 배포된 VRRP 세션의 경우, failover-delay 구성은 영향을 미치지 않습니다.