가상 라우터 이중화 프로토콜
Virtual Router Redundancy ProtocolVRRP(가상 라우터 중복 프로토콜)는 참여 호스트에 사용 가능한 IP(인터넷 프로토콜) 라우터를 자동으로 할당하도록 하는 컴퓨터 네트워킹 프로토콜이다.이것은 IP 하위 네트워크에서 자동 기본 게이트웨이 선택을 통해 라우팅 경로의 가용성과 신뢰성을 증가시킨다.
프로토콜은 여러 라우터, 즉 기본/활성 및 보조/대기 라우터의 추상적인 표현인 가상 라우터의 생성에 의해 이를 달성하며, 그룹으로서의 역할을 한다.가상 라우터는 물리적 라우터 대신 참여하는 호스트의 기본 게이트웨이 역할을 하도록 할당된다.가상 라우터를 대신하여 패킷을 라우팅하는 물리적 라우터가 실패할 경우, 다른 물리적 라우터가 자동으로 그것을 대체하도록 선택된다.주어진 시간에 패킷을 포워딩하는 물리적 라우터를 Primary/Active 라우터라고 한다.
VRRP는 라우터에 의해 처리되고 교환되는 경로가 아닌 라우터 상태에 대한 정보를 제공한다.각 VRRP 인스턴스는 단일 서브넷으로 제한된다.그것은 그 서브넷을 넘어서는 IP 경로를 광고하거나 라우팅 테이블에 어떤 식으로든 영향을 미치지 않는다.VRRP는 IPv6뿐만 아니라 인터넷 프로토콜 버전 4(IPv4)를 가진 이더넷, MPLS, 토큰 링 네트워크에서 사용될 수 있다.
그 프로토콜 인터넷 엔지니어링 태스크 포스(IETF)출판 RFC5798, 개방형 표준에 시스코는 그 과정이 기본적으로 그 똑같은 시설과 비슷한 프로토콜과 허가 특허를 받았다면 그것은 주장한다;[1] 하지만, 2001년에 직접 요청에 대한 답변으로 로버트 바 시스코의 어떤 특허 주장하지 않는 한을 주장하지 않겠으니 설명되어 있다. somerset.eone은 시스코에 대한 주장을 주장하려고 시도했다.[2]IBM은 특허에 관한 내용도 IETF 웹페이지에서 읽을 수 있다고 주장한다.[3][clarification needed]
실행
가상 라우터는 반드시 00-00-5E-00-01-XX를 해당 MAC(Media Access Control) 주소로 사용해야 한다.주소(XX)의 마지막 바이트는 VRID(가상 라우터 식별자)로, 네트워크의 각 가상 라우터에 대해 다르다.이 주소는 한 번에 하나의 물리적 라우터에서만 사용되며, 가상 라우터의 IP 주소에 대한 ARP 요청이 전송될 때 이 MAC 주소로 응답한다.
가상 라우터 내의 물리적 라우터는 멀티캐스트 IP 주소 224.0.0.18과 IP 프로토콜 번호 112를 가진 패킷을 사용하여 자신들 안에서 통신해야 한다.[4]
라우터는 1에서 254 사이의 우선 순위를 가지며 우선 순위가 가장 높은 라우터가 1차/활성화된다.기본 우선 순위는 100이며, MAC 주소 소유자의 경우 우선 순위는 항상 255이다.
Primary/Active 라우터 선택
광고 타이머의 3배가 넘는 기간 동안 Primary/Active 라우터에서 멀티캐스트 패킷을 수신하지 못하면 Secondary/Standby 라우터가 Primary/Active 라우터가 비활성 상태라고 가정하게 된다.그런 다음 가상 라우터가 불안정 상태로 전환되고 보조/대기 라우터에서 다음 기본/활성 라우터를 선택하기 위한 선택 프로세스가 시작된다.이것은 멀티캐스트 패킷의 사용을 통해 충족된다.
2차/대기 라우터는 선택 과정 중에 멀티캐스트 패킷만 전송하도록 되어 있다.이 규칙의 한 가지 예외는 물리적 라우터가 현재 Primary/Active보다 높은 우선 순위로 구성된 경우로, 이는 네트워크 연결 시 Primary/Active 상태를 선점한다는 것을 의미한다.이를 통해 시스템 관리자는 부팅 직후 물리적 라우터를 Primary/Active 상태로 강제 이동시킬 수 있으며, 예를 들어 특정 라우터가 가상 라우터 내의 다른 라우터보다 강력할 때 그러하다.우선순위가 가장 높은 보조/대기 라우터는 현재 기본/활성 라우터보다 우선순위를 높임으로써 기본/활성 라우터가 된다.그런 다음 가상 게이트웨이의 MAC 주소로 전송된 패킷을 라우팅하는 책임을 진다.Secondary/Standby 라우터가 모두 동일한 우선 순위를 갖는 경우, IP 주소가 가장 높은 Secondary/Standby 라우터는 Primary/Active 라우터가 된다.
가상 라우터 역할을 하는 모든 물리적 라우터는 동일한 LAN(local area network) 세그먼트에 있어야 한다.가상 라우터 내의 통신은 주기적으로 이루어진다.이 기간은 광고 간격 타이머를 변경하여 조정할 수 있다.광고 간격이 짧을수록 네트워크 트래픽이 많아지지만 블랙홀 기간은 짧아진다.보안은 특히 국지적 공격에 대해 이를 강화하기 위한 다른 메커니즘이 제공되지만, 첫 번째 홉 패킷에만 대응함으로써 달성된다.선거 과정은 라우터의 우선순위에서 파생된 스큐타임의 사용을 통해 질서 있게 만들어지며, 선거 기간 동안 우레와 같은 무리 문제가 발생할 가능성을 줄이는 데 사용된다.스큐 시간은 공식 (256 - Priority)/256 (밀리초 단위로 표시)에 의해 주어진다.
2차/대기 라우터 활용도는 로드 공유를 통해 개선할 수 있다.[5]
역사
VRRP는 Cisco의 독점적인 HSRP(Hot Standby Router Protocol) 개념을 기반으로 한다.프로토콜은 개념은 비슷하지만 양립할 수 없다.
파생상품
멜라노스는 액티브-액티브 연산이 가능한 VRRP 기반의 독점 프로토콜인 MAGP를 제공한다.[6]
Foundry Networks는 RFC 3768[7][1]의 몇 가지 제한을 피하는 VRRP의 독점 버전인 VRRP-E(Extended)를 개발했다.
참고 항목
- 공통 주소 중복 프로토콜(CARP) – HSRP 및 VRRP에 대한 비수용, 특허 및 무제한 대안
- 게이트웨이 로드 밸런싱 프로토콜 – 로드 밸런싱을 제공하는 Cisco 시스템즈 전용 라우터 이중화 프로토콜
- Hot Standby 라우팅 프로토콜 – Cisco 시스템즈 독점 라우터 이중화 프로토콜
- First Hop Drivation Protocols – 기본 게이트웨이 중복 프로토콜 목록
- RSMLT
참조
- ^ IETF 소스
- ^ Alexandre Cassen (2001-11-30). "[VRRP & OpenSource] Cisco answer". LVS mailing list. Retrieved 2013-11-28.
Robert Barr, from CISCO Systems: Cisco will not assert any patent claims against anyone for an implementation of IETF standard for VRRP unless a patent claim is asserted against Cisco, in which event Cisco reserves the right to assert patent claims defensively.
- ^ Chuck Adams, IBM (2003-04-15). "IBM Patent Disclosure and Licensing Statement Regarding IETF RFC 2338". IETF. Retrieved 2013-11-28.
- ^ Nadas, Stephen (March 2010). "Protocol". VRRPv3 for IPv4 and IPv6. sec. 5.1.1.4. doi:10.17487/RFC5798. RFC 5798.
- ^ Nadas, Stephen (March 2010). "Sample Configuration 2". VRRPv3 for IPv4 and IPv6. sec. 4.2. doi:10.17487/RFC5798. RFC 5798.
- ^ "HowTo Configure MAGP on Mellanox Switches". Retrieved 2010-01-21.
- ^ "VRRP-Ev2 overview". docs.ruckuswireless.com. Retrieved 2021-06-07.
외부 링크
- "The IETF VRRP mailing list archive".
- Nadas, Stephen (March 2010). VRRPv3 for IPv4 and IPv6. doi:10.17487/RFC5798. RFC 5798.
- Hinden, Robert (April 2004). Virtual Router Redundancy Protocol (VRRP). doi:10.17487/RFC3768. RFC 3768. 구 버전.