VRRP 이해
VRRP(Virtual Router Redundancy Protocol)를 사용하여 LAN에 가상 중복 라우팅 플랫폼을 생성하여 단일 라우팅 플랫폼에 의존하지 않고 LAN의 트래픽을 라우팅할 수 있습니다.
VRRP 이해
이더넷, 고속 이더넷, 기가비트 이더넷, 10기가비트 이더넷 및 논리적 인터페이스의 경우 IPv6용 VRRP(Virtual Router Redundancy Protocol) 또는 VRRP를 구성할 수 있습니다. VRRP를 사용하면 LAN의 호스트가 호스트에서 단일 기본 경로의 정적 구성 이상을 요구하지 않고도 해당 LAN에서 중복 라우팅 플랫폼을 사용할 수 있습니다. VRRP 라우팅 플랫폼은 호스트에 구성된 기본 경로에 해당하는 IP 주소를 공유합니다. 언제든지 VRRP 라우팅 플랫폼 중 하나는 기본(활성)이고 나머지는 백업입니다. 기본 라우팅 플랫폼에 장애가 발생하면 백업 라우팅 플랫폼 중 하나가 새로운 기본 라우팅 플랫폼이 되어 가상 기본 라우팅 플랫폼을 제공하고 단일 라우팅 플랫폼에 의존하지 않고 LAN의 트래픽을 라우팅할 수 있습니다. VRRP를 사용하면 백업 디바이스가 몇 초 안에 장애가 발생한 기본 디바이스를 인수할 수 있습니다. 이는 호스트와의 상호 작용 없이 최소한의 VRRP 트래픽으로 수행됩니다. 가상 라우터 이중화 프로토콜은 관리 인터페이스에서 지원되지 않습니다.
VRRP를 실행하는 디바이스는 기본 디바이스와 백업 디바이스를 동적으로 선택합니다. 또한 1에서 255까지의 우선 순위를 사용하여 기본 및 백업 디바이스를 강제로 할당할 수 있으며, 255가 가장 높은 우선 순위입니다. VRRP 작업에서 기본 기본 디바이스는 정기적으로 백업 디바이스에 보급을 보냅니다. 기본 간격은 1초입니다. 백업 디바이스가 설정된 기간 동안 보급을 받지 않으면 우선 순위가 두 번째로 높은 백업 디바이스가 기본으로 인계되어 패킷 전달을 시작합니다.
라우팅된 VLAN 인터페이스(RVI)에 대해 우선 순위 255를 설정할 수 없습니다.
VRRP는 네트워크 트래픽을 최소화하기 위해 기본 역할을 하는 디바이스만 특정 시점에 VRRP 광고를 전송하는 방식으로 설계되었습니다. 백업 디바이스는 기본 역할을 인계받기 전까지는 어떠한 보급도 보내지 않습니다.
IPv6용 VRRP는 IPv6 인접 항목 검색 절차보다 대체 기본 라우터로 훨씬 빠른 전환을 제공합니다. 일반적인 구축에서는 백업 라우터가 하나만 사용됩니다.
VRRP 기본 및 백업 라우팅 플랫폼을 Virtual Chassis 구성의 기본 및 백업 멤버 스위치와 혼동하지 마십시오. Virtual Chassis 구성의 기본 및 백업 멤버는 단일 호스트를 구성합니다. 그림 3과 같이 VRRP 토폴로지에서 하나의 호스트는 기본 라우팅 플랫폼으로 작동하고 다른 호스트는 백업 라우팅 플랫폼으로 작동합니다.
VRRP는 RFC 3768, 가상 라우터 이중화 프로토콜에 정의되어 있습니다. IPv6에 대한 VRRP는 draft-ietf-vrrp-ipv6-spec-08.txt, IPv6에 대한 가상 라우터 중복 프로토콜에 정의되어 있습니다. draft-ietf-vrrp-unified-mib-06.txt, IPv4 및 IPv6을 통한 VRRP에 대한 매니지드 객체의 정의도 참조하십시오.
RFC 3768에 정의된 VRRP는 인증을 지원하지 않지만, VRRP의 Junos OS 구현은 RFC 2338에 정의된 인증을 지원합니다. 이 지원은 RFC 3768의 이전 버전과의 호환성 옵션을 통해 달성됩니다.
EX2300 및 EX3400 스위치에서 VRRP 프로토콜은 라우팅 엔진 전환, 인터페이스 플랩, 패킷 전달 엔진에서의 철저한 데이터 수집과 같은 CPU 집약적인 작업 이벤트 중 플랩을 방지하기 위해 2초 이상의 Hello 간격과 6초 이상의 데드 간격으로 구성되어야 합니다.
그림 1은 기본 VRRP 토폴로지를 보여줍니다. 이 예에서 라우터 A, B, C는 VRRP를 실행하며 함께 가상 라우터를 구성합니다. 이 가상 라우터의 IP 주소는 10.10.0.1(라우터 A의 물리적 인터페이스와 동일한 주소)입니다.
가상 라우터는 라우터 A의 물리적 인터페이스의 IP 주소를 사용하기 때문에 라우터 A는 기본 VRRP 라우터이고 라우터 B와 C는 백업 VRRP 라우터의 기능을 합니다. 클라이언트 1에서 3은 기본 게이트웨이 IP 주소 10.10.0.1로 구성됩니다. 기본 라우터인 라우터 A는 IP 주소로 전송된 패킷을 전달합니다. 기본 가상 라우터에 장애가 발생하면 우선 순위가 높은 라우터가 기본 가상 라우터가 되어 LAN 호스트에 중단 없는 서비스를 제공합니다. 라우터 A가 복구되면 다시 기본 가상 라우터가 됩니다.
경우에 따라 상속 세션 중에 두 개의 라우터가 기본-기본 상태에 있는 짧은 시간 프레임이 있습니다. 이러한 경우 상태를 상속하는 VRRP 그룹은 120초마다 VRRP 보급을 보냅니다. 따라서 라우터가 기본-기본 상태에서 기본-백업 상태로 이동한 후 복구하는 데 최대 120초가 걸립니다.
ACX 시리즈 라우터는 최대 64개의 VRRP 그룹 항목을 지원할 수 있습니다. IPv4 또는 IPv6 패밀리의 조합일 수 있습니다. 패밀리(IPv4 또는 IPv6) 중 하나가 VRRP에만 구성된 경우, 64개의 고유한 VRRP 그룹 식별자가 지원됩니다. IPv4와 IPv6 패밀리가 모두 동일한 VRRP 그룹을 공유하는 경우, 32개의 고유 VRRP 식별자만 지원됩니다.
ACX 시리즈 라우터는 IPv6 주소에 대해 VRRP 버전 3을 지원합니다.
ACX5448 라우터는 RFC 3768 VRRP 버전 2 및 RFC 5798 VRRP 버전 3을 지원합니다. ACX5448 라우터는 또한 어그리게이션 이더넷 및 통합 라우팅 및 브리징(IRB) 인터페이스를 통한 VRRP 구성을 지원합니다.
ACX5448 라우터에서 VRRP를 구성하는 동안 다음과 같은 제한 사항이 적용됩니다.
-
최대 16개의 VRRP 그룹을 구성합니다.
-
VRRP 버전 2와 VRRP 버전 3의 연동은 지원되지 않습니다.
-
VRRP 대리자 처리는 지원되지 않습니다.
-
VRRP 버전 2 인증은 지원되지 않습니다.
그림 1 은 EX 시리즈 스위치의 기본 VRRP 토폴로지를 보여줍니다. 이 예에서 스위치 A, B, C는 VRRP를 실행하며 함께 가상 라우팅 플랫폼을 구성합니다. 이 가상 라우팅 플랫폼의 IP 주소는 (스위치 A의 물리적 인터페이스와 동일한 주소)입니다 10.10.0.1 .
의 기본 VRRP
그림 3 은 Virtual Chassis 구성을 사용하는 기본 VRRP 토폴로지를 보여줍니다. 스위치 A, 스위치 B 및 스위치 C는 각각 상호 연결된 여러 개의 주니퍼 네트웍스 EX4200 이더넷 스위치로 구성됩니다. 각 Virtual Chassis 구성은 VRRP를 실행하는 단일 스위치로 작동하며 함께 가상 라우팅 플랫폼을 구성합니다. 이 가상 라우팅 플랫폼의 IP 주소는 (스위치 A의 물리적 인터페이스와 동일한 주소)입니다 10.10.0.1 .
의 VRRP
가상 라우팅 플랫폼은 스위치 A의 물리적 인터페이스의 IP 주소를 사용하기 때문에 스위치 A가 기본 VRRP 라우팅 플랫폼이고 스위치 B와 스위치 C는 백업 VRRP 라우팅 플랫폼으로 작동합니다. 클라이언트 1에서 3은 기본 게이트웨이 IP 주소로 10.10.0.1 구성되며, 기본 라우터인 스위치 A는 해당 IP 주소로 전송된 패킷을 전달합니다. 기본 라우팅 플랫폼에 장애가 발생하면 우선 순위가 높은 스위치가 기본 가상 라우팅 플랫폼이 되고 LAN 호스트에 중단 없는 서비스를 제공합니다. 스위치 A가 복구되면 다시 기본 가상 라우팅 플랫폼이 됩니다.
IPv6용 VRRP 및 VRRP 개요
다음 인터페이스에 대해 IPv6용 VRRP(Virtual Router Redundancy Protocol) 및 VRRP를 구성할 수 있습니다.
이더넷
고속 이더넷
삼중 속도 이더넷 구리
기가비트 이더넷
10기가비트 이더넷 LAN/WAN PIC
이더넷 논리적 인터페이스
IPv6용 VRRP 및 VRRP를 사용하면 LAN의 호스트가 호스트에서 단일 기본 경로의 정적 구성 이상을 요구하지 않고도 해당 LAN에서 중복 라우터를 사용할 수 있습니다. VRRP 라우터는 호스트에 구성된 기본 경로에 해당하는 IP 주소를 공유합니다. 언제든지 VRRP 라우터 중 하나는 기본(활성)이고 나머지는 백업입니다. 기본 라우터에 장애가 발생하면 백업 라우터 중 하나가 새로운 기본 라우터가 되므로 항상 가상 기본 라우터를 제공하고 단일 라우터에 의존하지 않고 LAN의 트래픽을 라우팅할 수 있습니다.
VRRP는 RFC 3768, 가상 라우터 이중화 프로토콜에 정의되어 있습니다.
IPv6용 VRRP 및 VRRP 개요 정보, 구성 지침 및 문 요약은 Junos OS 고가용성 사용자 가이드를 참조하십시오.
VRRPv3에 대한 Junos OS 지원
VRRPv3를 사용하면 VRRPv3는 IPv4와 IPv6 주소 패밀리를 모두 지원하는 반면 VRRPv2는 IPv4 주소만 지원한다는 장점이 있습니다.
다음 주제에서는 VRRPv3에 대한 Junos OS 지원 및 상호 운용성 및 VRRPv3와 그 이전 플랫폼 간의 몇 가지 차이점에 대해 설명합니다.
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에 대해서도 지원되지 않습니다.
IPv6용 VRRPv3는 QFX10002-60C에서 지원됩니다.
릴리스 12.2부터 Junos OS는 다음을 지원합니다.
RFC 3768, VRRP(Virtual Router Redundancy Protocol)
RFC 5798, IPv4 및 IPv6에 대한 VRRP(Virtual Router Redundancy Protocol) 버전 3
RFC 6527, 가상 라우터 중복 프로토콜 버전 3(VRRPv3)에 대한 매니지드 객체의 정의
Junos OS 릴리스 12.2 이상 릴리스를 사용하는 라우터의 VRRP(IPv6용)는 VRRP 체크섬 계산의 차이로 인해 이전 Junos OS 릴리스를 사용하는 라우터의 VRRP(IPv6용)와 상호 운용되지 않습니다. IPv6 VRRP 체크섬 동작 차이를 참조하십시오.
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, IPv4 및 IPv6에 대한 가상 라우터 중복 프로토콜(VRRP) 버전 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하십시오.tcpdumpJunos OS 릴리스 12.2 및 이후 버전의 유틸리티는 IPv4 및 IPv6에 대한 RFC 5798, VRRP(Virtual Router Redundancy Protocol) 버전 3에 따라 VRRP 체크섬을 계산합니다. 따라서tcpdump이전 Junos OS 릴리스(Junos OS 릴리스 12.2bad vrrp cksum이전)에서 수신된 IPv6 VRRP 패킷을 구문 분석하면 메시지가 표시됩니다.23:20:32.657328 Out ... -----original packet----- 00:00:5e:00:02:03 > 33:33:00:00:00:12, ethertype IPv6 (0x86dd), length 94: (class 0xc0, hlim 255, next-header: VRRP (112), length: 40) fe80::224:dcff:fe47:57f > ff02::12: VRRPv3-advertisement 40: vrid=3 prio=100 intvl=100(centisec) (bad vrrp cksum b4e2!) addrs(2): fe80::200:5eff:fe00:3,2001:4818:f000:14::1 3333 0000 0012 0000 5e00 0203 86dd 6c00 0000 0028 70ff fe80 0000 0000 0000 0224 dcff fe47 057f ff02 0000 0000 0000 0000 0000 0000 0012 3103 6402 0064 b4e2 fe80 0000 0000 0000 0200 5eff fe00 0003 2001 4818 f000 0014 0000 0000 0000 0001이 메시지는 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 릴리스와 상호 운용되도록 하려면 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와 상호 운용되지 않습니다. VRRPv3가 활성화된 라우터가 VRRPv2 IPv4 광고 패킷을 수신하면 라우터는 네트워크에서 여러 기본이 생성되지 않도록 스스로 백업 상태로 전환됩니다. 이 동작으로 인해 기존 VRRPv2 네트워크에서 VRRPv3를 활성화할 때 주의해야 합니다. 자세한 내용은 VRRPv2에서 VRRPv3으로 업그레이드 를 참조하십시오.
참고:VRRPv3 광고 패킷은 이전 버전의 VRRP가 구성된 라우터에서 무시됩니다.
VRRPv2에서 VRRPv3으로 업그레이드
네트워크의 모든 VRRP 라우터에서 VRRPv3를 활성화할 수 있는 경우에만 네트워크에서 VRRPv3를 활성화하십시오.
VRRPv2에서 VRRPv3로 업그레이드할 때만 VRRPv2 네트워크에서 VRRPv3를 활성화합니다. 두 버전의 VRRP를 혼합하는 것은 영구적인 솔루션이 아닙니다.
VRRP 버전 변경은 치명적이고 파괴적인 것으로 간주되며 중단이 발생하지 않을 수 있습니다. 패킷 손실 기간은 VRRP 그룹의 수, 관련된 인터페이스 및 FPC, 라우터에서 실행되는 다른 서비스 및 프로토콜의 부하 등 여러 요인에 따라 달라집니다.
VRRPv2에서 VRRPv3로의 업그레이드는 다음과 같은 고려 사항으로 인해 트래픽 손실을 방지하기 위해 매우 신중하게 수행해야 합니다.
모든 라우터에서 동시에 VRRPv3를 구성할 수는 없습니다.
전환 기간 동안 VRRPv2와 VRRPv3 모두 네트워크에서 작동합니다.
VRRP 버전을 변경하면 모든 VRRP 그룹에 대한 상태 시스템이 다시 시작됩니다.
VRRPv3(IPv4용) 라우터는 VRRPv2(IPv4용) 광고 패킷을 수신하면 기본적으로 백업 상태로 설정됩니다.
VRRPv2(IPv4용) 패킷은 항상 가장 높은 우선 순위가 부여됩니다.
VRRPv2와 VRRPv3(IPv6용) 간의 체크섬 차이로 인해 여러 개의 기본 라우터가 생성될 수 있습니다.
업그레이드하는 동안 백업 라우터에서 VRRPv3(IPv6용)를 비활성화하여 여러 기본 라우터가 생성되지 않도록 합니다.
표 1 은 VRRPv2에서 VRRPv3으로 전환하는 동안 발생하는 단계와 이벤트를 보여줍니다. 표 1에서는 두 개의 VRRPv2 라우터 R1과 R2가 G1과 G2의 두 그룹으로 구성되어 있습니다. 라우터 R1은 G1의 기본 역할을 하고 라우터 R2는 G2의 기본 역할을 합니다.
|
|
For IPv4 |
For IPv6 |
|
|
VRRPv3를 활성화할 때 VRRPv3(IPv4)는 이전 버전의 VRRP와 상호 운용되지 않기 때문에 네트워크의 모든 VRRP 라우터에서 VRRPv3가 활성화되어 있는지 확인합니다. 예를 들어, VRRPv3이 활성화된 라우터에서 VRRPv2 IPv4 광고 패킷을 수신하면 라우터는 네트워크에서 여러 기본이 생성되지 않도록 스스로 백업 상태로 전환됩니다.
계층 수준(IPv4 또는 IPv6 네트워크용)에서 [edit protocols vrrp] 문을 구성 version-3 하여 VRRPv3를 활성화할 수 있습니다. LAN의 모든 VRRP 라우터에서 동일한 프로토콜 버전을 구성합니다.
VRRPv3 기능의 기능
일부 Junos OS 기능은 VRRPv3에서 이전 VRRP 버전과 다릅니다.
VRRPv3 인증
VRRPv3(IPv4용)가 활성화되면 인증이 허용되지 않습니다.
authentication-typeandauthentication-key문은 VRRP 그룹에 대해 구성할 수 없습니다.비 VRRP 인증을 사용해야 합니다.
VRRPv3 광고 간격
VRRPv3(IPv4 및 IPv6용) 광고 간격은 계층 수준에서 [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] 문으로 fast-interval 설정해야 합니다.
(IPv4의 경우) 문은
advertise-interval사용하지 마십시오.(IPv6의 경우) 문을
inet6-advertise-interval사용하지 마십시오.
VRRPv3를 위한 통합 ISSU
VRRP 통합 ISSU(In-Service Software Upgrade)에 대한 설계가 Junos OS 릴리스 15.1에서 변경되어 다음 기능을 구현합니다.
통합 ISSU 동안 피어 라우터와의 프로토콜 인접성을 유지합니다. 통합 ISSU를 수행하는 라우터에 대해 피어 라우터에서 생성된 프로토콜 인접성은 플랩되지 않아야 하며, 이는 원격 피어 라우터의 VRRP가 플랩되지 않아야 한다는 것을 의미합니다.
경쟁 장비 또는 보완 장비와의 상호 운용성 유지
다른 Junos OS 릴리스 및 다른 주니퍼 네트워크 제품과의 상호 운용성을 유지합니다.
통합 ISSU를 지원하기 위해 다음 구성의 값(계층 수준에서 [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] 발견)을 최대값으로 유지해야 합니다.
기본 라우터에서 광고 간격(문)
fast-interval은 40950밀리초로 유지되어야 합니다.백업 라우터에서 기본 다운 간격(문
advertisements-threshold)은 가장 큰 임계값으로 유지되어야 합니다.
이 VRRP 통합 ISSU 설계는 VRRPv3에서만 작동합니다. VRRPv1 또는 VRRPv2에서는 지원되지 않습니다. 다른 제한 사항은 다음과 같습니다.
VRRP 통합 ISSU는 VRRP만 처리합니다. 패킷 전달은 패킷 포워딩 엔진의 책임입니다. 패킷 포워딩 엔진 통합 ISSU는 중단 없는 트래픽 흐름을 보장해야 합니다.
VRRP는 통합 ISSU 도중 변경 이벤트의 영향을 받지 않습니다(예: 기본 라우팅 엔진에서 백업으로 또는 백업 라우팅 엔진에서 기본으로 전환).
VRRP는 통합 ISSU에 들어가기 전에 실행 중인 타이머를 중지하고 폐기할 수 있습니다. 이는 타이머 만료 시 예상되는 작업이 절대 발생하지 않는다는 것을 의미합니다. 그러나 모든 실행 타이머가 만료될 때까지 통합 ISSU를 연기할 수 있습니다.
로컬 및 원격 라우터 모두에서 통합 ISSU를 동시에 수행할 수 없습니다.
VRRP 장애 조치-지연 개요
페일오버는 장애 또는 예정된 다운타임으로 인해 주 디바이스를 사용할 수 없게 될 때 보조 디바이스가 네트워크 디바이스의 기능을 인계하는 백업 운영 모드입니다. 페일오버는 일반적으로 네트워크에서 지속적으로 사용 가능해야 하는 미션 크리티컬 시스템의 필수적인 부분입니다.
VRRP는 멤버 간의 세션 동기화를 지원하지 않습니다. 기본 디바이스에 장애가 발생하면 우선 순위가 가장 높은 백업 디바이스가 기본 디바이스로 인계되어 패킷 전송을 시작합니다. 기존 세션은 상태 외 상태로 백업 디바이스에서 삭제됩니다.
빠른 장애 조치에는 짧은 지연이 필요합니다. 따라서 failover-delay는 IPv6 작업의 VRRP 및 VRRP에 대한 페일오버 지연 시간을 밀리초 단위로 구성합니다. Junos OS는 페일오버 시간 지연에 대해 50에서 100,000밀리초 사이를 지원합니다.
라우팅 엔진에서 실행되는 VRRP 프로세스(vrrpd)는 모든 VRRP 세션에 대해 VRRP 기본 역할 변경을 패킷 포워딩 엔진에 전달합니다. 각 VRRP 그룹은 이러한 통신을 트리거하여 패킷 포워딩 엔진을 자체 상태 또는 활성 VRRP 그룹에서 상속된 상태로 업데이트할 수 있습니다. 이러한 메시지로 패킷 포워딩 엔진에 과부하가 걸리지 않도록 페일오버 지연을 구성하여 후속 라우팅 엔진에서 패킷 포워딩 엔진 통신 사이의 지연을 지정할 수 있습니다.
라우팅 엔진는 VRRP 기본 역할 변경을 패킷 포워딩 엔진에 전달하여 패킷 포워딩 엔진 하드웨어 필터, VRRP 세션 등의 재프로그래밍과 같은 패킷 포워딩 엔진에서 필요한 상태 변경을 용이하게 합니다. 다음 섹션에서는 두 가지 시나리오에서 라우팅 엔진에서 패킷 포워딩 엔진으로의 통신에 대해 자세히 설명합니다.
failover-delay가 구성되지 않은 경우
장애 조치 지연이 구성되지 않은 경우, 라우팅 엔진에서 운영되는 VRRP 세션에 대한 이벤트 시퀀스는 다음과 같습니다.
라우팅 엔진이 감지한 첫 번째 VRRP 그룹이 상태를 변경하고 새로운 상태가 기본이면 라우팅 엔진은 적절한 VRRP 공지 메시지를 생성합니다. 패킷 포워딩 엔진은 상태 변경에 대한 정보를 받으므로 해당 그룹에 대한 하드웨어 필터가 지연 없이 다시 프로그래밍됩니다. 그런 다음 새 기본은 VRRP 그룹에 Gratuitous ARP 메시지를 보냅니다.
장애 조치 타이머의 지연이 시작됩니다. 기본적으로 장애 조치-지연 타이머는 다음과 같습니다.
500밀리초 - 구성된 VRRP 공지 간격이 1초 미만인 경우.
2초 - 구성된 VRRP 공지 간격이 1초 이상이고 라우터의 총 VRRP 그룹 수가 255인 경우.
10초 - 구성된 VRRP 공지 간격이 1초 이상이고 라우터의 VRRP 그룹 수가 255를 초과하는 경우.
라우팅 엔진은 후속 VRRP 그룹에 대해 하나씩 상태 변경을 수행합니다. 상태 변경이 있고 특정 VRRP 그룹의 새 상태가 기본일 때마다 라우팅 엔진은 적절한 VRRP 공지 메시지를 생성합니다. 그러나 패킷 포워딩 엔진에 대한 통신은 장애 조치 지연 타이머가 만료될 때까지 억제됩니다.
장애 조치 지연 타이머가 만료된 후, 라우팅 엔진은 상태를 변경한 모든 VRRP 그룹에 대한 메시지를 패킷 포워딩 엔진에 보냅니다. 그 결과, 이러한 그룹에 대한 하드웨어 필터가 다시 프로그래밍되고, 새 상태가 기본인 그룹에 대해서는 Gratuitous ARP 메시지가 전송됩니다.
이 프로세스는 모든 VRRP 그룹에 대한 상태 전환이 완료될 때까지 반복됩니다.
따라서, 페일오버 지연을 구성하지 않고, 첫 번째 VRRP 그룹에 대한 전체 상태 전환(라우팅 엔진 및 패킷 포워딩 엔진의 상태 포함)이 즉시 수행되는 반면, 나머지 VRRP 그룹에 대한 패킷 포워딩 엔진의 상태 전환은 구성된 VRRP 공지 타이머와 VRRP 그룹 수에 따라 최소 0.5-10초 지연됩니다. 이 중간 상태 동안, 패킷 포워딩 엔진에서 아직 완료되지 않은 상태 변경에 대한 VRRP 그룹에 대한 트래픽 수신은 하드웨어 필터의 재구성 지연으로 인해 패킷 포워딩 엔진 수준에서 드롭될 수 있습니다.
failover-delay가 구성된 경우
failover-delay가 구성된 경우, 라우팅 엔진에서 운영되는 VRRP 세션에 대한 이벤트 시퀀스는 다음과 같이 수정됩니다.
라우팅 엔진은 일부 VRRP 그룹에 상태 변경이 필요함을 감지합니다.
페일오버 지연은 구성된 기간 동안 시작됩니다. 허용되는 장애 조치-지연 타이머 범위는 50에서 100,000밀리초입니다.
라우팅 엔진은 VRRP 그룹에 대해 하나씩 상태 변경을 수행합니다. 상태 변경이 있고 특정 VRRP 그룹의 새 상태가 기본일 때마다 라우팅 엔진은 적절한 VRRP 공지 메시지를 생성합니다. 그러나 패킷 포워딩 엔진에 대한 통신은 장애 조치 지연 타이머가 만료될 때까지 억제됩니다.
장애 조치 지연 타이머가 만료된 후, 라우팅 엔진은 상태를 변경한 모든 VRRP 그룹에 대한 메시지를 패킷 포워딩 엔진에 보냅니다. 그 결과, 이러한 그룹에 대한 하드웨어 필터가 다시 프로그래밍되고, 새 상태가 기본인 그룹에 대해서는 Gratuitous ARP 메시지가 전송됩니다.
이 프로세스는 모든 VRRP 그룹에 대한 상태 전환이 완료될 때까지 반복됩니다.
따라서, 페일오버 지연이 구성되면 첫 번째 VRRP 그룹에 대한 패킷 포워딩 엔진 상태도 지연됩니다. 그러나 네트워크 운영자는 VRRP 상태 변경 중 중단을 최소화하기 위해 네트워크 구축의 요구에 가장 적합한 장애 조치 지연 값을 구성할 수 있는 이점이 있습니다.
failover-delay는 라우팅 엔진에서 실행되는 VRRP 프로세스(vrrpd)에 의해 운영되는 VRRP 세션에만 영향을 미칩니다. 패킷 포워딩 엔진에 배포된 VRRP 세션의 경우, 장애 조치-지연 구성은 효과가 없습니다.
변경 내역 표
기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. 기능 탐색기를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.