[要約] RFC 5798は、IPv4およびIPv6のためのVirtual Router Redundancy Protocol（VRRP）バージョン3に関する規格です。このRFCの目的は、ネットワークの冗長性を確保し、仮想ルーターの冗長性を提供するためのプロトコルを定義することです。
Internet Engineering Task Force (IETF) S. Nadas, Ed.
Request for Comments: 5798 Ericsson
Obsoletes: 3768 March 2010
Category: Standards Track
ISSN: 2070-1721
Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
IPv4およびIPv6用の仮想ルーター冗長プロトコル（VRRP）バージョン3
Abstract
概要
This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms.
このメモは、IPv4およびIPv6の仮想ルーター冗長プロトコル（VRRP）を定義します。これはプロトコルのバージョン3であり、RFC 3768および「IPv6の仮想ルーター冗長プロトコル」で定義されているIPv4のVRRP（バージョン2）に基づいています。 VRRPは、LAN上のVRRPルーターの1つに仮想ルーターの責任を動的に割り当てる選挙プロトコルを指定します。仮想ルーターに関連付けられたIPv4またはIPv6アドレスを制御するVRRPルーターはマスターと呼ばれ、これらのIPv4またはIPv6アドレスに送信されたパケットを転送します。 VRRPマスタールーターは仮想IPv4またはIPv6アドレスで構成され、VRRPバックアップルーターはトランスポートプロトコルに基づいて伝送される仮想アドレスのアドレスファミリーを推測します。 VRRPルーター内では、IPv4およびIPv6の各アドレスファミリーの仮想ルーターはそれ自体がドメインであり、重複しません。マスターが使用できなくなった場合、選定プロセスにより、転送の責任において動的なフェイルオーバーが提供されます。 IPv4の場合、VRRPを使用することで得られる利点は、すべてのエンドホストで動的ルーティングまたはルーター検出プロトコルを構成する必要がない、より可用性の高いデフォルトパスです。 IPv6の場合、VRRP for IPv6を使用することで得られる利点は、標準のIPv6近隣探索メカニズムで得られるよりも、バックアップルーターへの切り替えが速くなることです。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5798.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5798で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. A Note on Terminology ......................................4
1.2. IPv4 .......................................................5
1.3. IPv6 .......................................................6
1.4. Requirements Language ......................................6
1.5. Scope ......................................................7
1.6. Definitions ................................................7
2. Required Features ...............................................8
2.1. IPvX Address Backup ........................................8
2.2. Preferred Path Indication ..................................8
2.3. Minimization of Unnecessary Service Disruptions ............9
2.4. Efficient Operation over Extended LANs .....................9
2.5. Sub-Second Operation for IPv4 and IPv6 .....................9
3. VRRP Overview ..................................................10
4. Sample Configurations ..........................................11
4.1. Sample Configuration 1 ....................................11
4.2. Sample Configuration 2 ....................................13
5. Protocol .......................................................14
5.1. VRRP Packet Format ........................................15
5.1.1. IPv4 Field Descriptions ............................15
5.1.1.1. Source Address ............................15
5.1.1.2. Destination Address .......................15
5.1.1.3. TTL .......................................16
5.1.1.4. Protocol ..................................16
5.1.2. IPv6 Field Descriptions ............................16
5.1.2.1. Source Address ............................16
5.1.2.2. Destination Address .......................16
5.1.2.3. Hop Limit .................................16
5.1.2.4. Next Header ...............................16
5.2. VRRP Field Descriptions ...................................16
5.2.1. Version ............................................16
5.2.2. Type ...............................................17
5.2.3. Virtual Rtr ID (VRID) ..............................17
5.2.4. Priority ...........................................17
5.2.5. Count IPvX Addr ....................................17
5.2.6. Rsvd ...............................................17
5.2.7. Maximum Advertisement Interval (Max Adver Int) .....17
5.2.8. Checksum ...........................................18
5.2.9. IPvX Address(es) ...................................18
6. Protocol State Machine .........................................18
6.1. Parameters Per Virtual Router .............................18
6.2. Timers ....................................................20
6.3. State Transition Diagram ..................................21
6.4. State Descriptions ........................................21
6.4.1. Initialize .........................................21
6.4.2. Backup .............................................22
6.4.3. Master .............................................24
7. Sending and Receiving VRRP Packets .............................26
7.1. Receiving VRRP Packets ....................................26
7.2. Transmitting VRRP Packets .................................27
7.3. Virtual Router MAC Address ................................28
7.4. IPv6 Interface Identifiers ................................28
8. Operational Issues .............................................29
8.1. IPv4 ......................................................29
8.1.1. ICMP Redirects .....................................29
8.1.2. Host ARP Requests ..................................29
8.1.3. Proxy ARP ..........................................30
8.2. IPv6 ......................................................30
8.2.1. ICMPv6 Redirects ...................................30
8.2.2. ND Neighbor Solicitation ...........................30
8.2.3. Router Advertisements ..............................31
8.3. IPvX ......................................................31
8.3.1. Potential Forwarding Loop ..........................31
8.3.2. Recommendations Regarding Setting Priority Values ..32
8.4. VRRPv3 and VRRPv2 Interoperation ..........................32
8.4.1. Assumptions ........................................32
8.4.2. VRRPv3 Support of VRRPv2 ...........................32
8.4.3. VRRPv3 Support of VRRPv2 Considerations ............33
8.4.3.1. Slow, High-Priority Masters ...............33
8.4.3.2. Overwhelming VRRPv2 Backups ...............33
9. Security Considerations ........................................33
10. Contributors and Acknowledgments ..............................34
11. IANA Considerations ...........................................35
12. References ....................................................35
12.1. Normative References .....................................35
12.2. Informative References ...................................36
Appendix A. Operation over FDDI, Token Ring, and ATM LANE .........38
A.1. Operation over FDDI .......................................38
A.2. Operation over Token Ring .................................38
A.3. Operation over ATM LANE ...................................40
This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol. It is based on VRRP (version 2) for IPv4 that is defined in [RFC3768] and in [VRRP-IPv6]. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable.
このメモは、IPv4およびIPv6の仮想ルーター冗長プロトコル（VRRP）を定義します。これはプロトコルのバージョン3です。 [RFC3768]と[VRRP-IPv6]で定義されているIPv4のVRRP（バージョン2）に基づいています。 VRRPは、LAN上のVRRPルーターの1つに仮想ルーターの責任を動的に割り当てる選挙プロトコルを指定します。仮想ルーターに関連付けられたIPv4またはIPv6アドレスを制御するVRRPルーターはマスターと呼ばれ、これらのIPv4またはIPv6アドレスに送信されたパケットを転送します。 VRRPマスタールーターは仮想IPv4またはIPv6アドレスで構成され、VRRPバックアップルーターはトランスポートプロトコルに基づいて伝送される仮想アドレスのアドレスファミリーを推測します。 VRRPルーター内では、IPv4およびIPv6の各アドレスファミリーの仮想ルーターはそれ自体がドメインであり、重複しません。マスターが使用できなくなった場合、選定プロセスにより、転送の責任において動的なフェイルオーバーが提供されます。
VRRP provides a function similar to the proprietary protocols "Hot Standby Router Protocol (HSRP)" [RFC2281] and "IP Standby Protocol" [IPSTB].
VRRPは、独自のプロトコル「ホットスタンバイルータープロトコル（HSRP）」[RFC2281]および「IPスタンバイプロトコル」[IPSTB]と同様の機能を提供します。
This document discusses both IPv4 and IPv6 operation, and with respect to the VRRP protocol, many of the descriptions and procedures are common. In this document, it would be less verbose to be able to refer to "IP" to mean either "IPv4 or IPv6". However, historically, the term "IP" usually refers to IPv4. For this reason, in this specification, the term "IPvX" (where X is 4 or 6) is introduced to mean either "IPv4" or "IPv6". In this text, where the IP version matters, the appropriate term is used and the use of the term "IP" is avoided.
このドキュメントでは、IPv4とIPv6の両方の操作について説明します。VRRPプロトコルに関しては、多くの説明と手順が共通です。このドキュメントでは、「IP」を「IPv4またはIPv6」のいずれかを意味するように参照できるようにするほうが冗長ではありません。ただし、歴史的に、「IP」という用語は通常IPv4を指します。このため、本明細書では、「IPvX」（Xは4または6）という用語は、「IPv4」または「IPv6」のいずれかを意味するように導入されています。このテキストでは、IPバージョンが重要な場合は、適切な用語を使用し、「IP」という用語の使用は避けています。
There are a number of methods that an IPv4 end-host can use to determine its first-hop router towards a particular IPv4 destination. These include running (or snooping) a dynamic routing protocol such as Routing Information Protocol [RFC2453] or OSPF version 2 [RFC2328], running an ICMP router discovery client [RFC1256], or using a statically configured default route.
IPv4エンドホストが特定のIPv4宛先へのファーストホップルーターを決定するために使用できる方法はいくつかあります。これには、ルーティング情報プロトコル[RFC2453]やOSPFバージョン2 [RFC2328]などの動的ルーティングプロトコルの実行（またはスヌーピング）、ICMPルーター発見クライアント[RFC1256]の実行、または静的に構成されたデフォルトルートの使用が含まれます。
Running a dynamic routing protocol on every end-host may be infeasible for a number of reasons, including administrative overhead, processing overhead, security issues, or lack of a protocol implementation for some platforms. Neighbor or router discovery protocols may require active participation by all hosts on a network, leading to large timer values to reduce protocol overhead in the face of large numbers of hosts. This can result in a significant delay in the detection of a lost (i.e., dead) neighbor; such a delay may introduce unacceptably long "black hole" periods.
すべてのエンドホストで動的ルーティングプロトコルを実行することは、管理オーバーヘッド、処理オーバーヘッド、セキュリティの問題、または一部のプラットフォームでのプロトコル実装の欠如など、さまざまな理由で実行できない場合があります。ネイバーまたはルーター検出プロトコルは、ネットワーク上のすべてのホストによるアクティブな参加を必要とする場合があり、多数のホストに直面した場合のプロトコルオーバーヘッドを削減するために、タイマー値が大きくなります。これにより、失われた（つまり、死んだ）ネイバーの検出に大幅な遅延が生じる可能性があります。このような遅延は、許容できないほど長い「ブラックホール」期間を引き起こす可能性があります。
The use of a statically configured default route is quite popular; it minimizes configuration and processing overhead on the end-host and is supported by virtually every IPv4 implementation. This mode of operation is likely to persist as dynamic host configuration protocols [RFC2131] are deployed, which typically provide configuration for an end-host IPv4 address and default gateway. However, this creates a single point of failure. Loss of the default router results in a catastrophic event, isolating all end-hosts that are unable to detect any alternate path that may be available.
静的に構成されたデフォルトルートの使用は非常に一般的です。エンドホストでの構成と処理のオーバーヘッドを最小限に抑え、事実上すべてのIPv4実装でサポートされています。動的ホスト構成プロトコル[RFC2131]が展開されているため、この動作モードは持続する可能性が高く、通常、エンドホストIPv4アドレスとデフォルトゲートウェイの構成を提供します。ただし、これは単一障害点を作成します。デフォルトルータが失われると、壊滅的なイベントが発生し、使用可能な代替パスを検出できないすべてのエンドホストが隔離されます。
The Virtual Router Redundancy Protocol (VRRP) is designed to eliminate the single point of failure inherent in the static default-routed environment. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 address(es) associated with a virtual router is called the Master and forwards packets sent to these IPv4 addresses. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. Any of the virtual router's IPv4 addresses on a LAN can then be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.
仮想ルーター冗長プロトコル（VRRP）は、静的デフォルト経路指定環境に固有の単一障害点を排除するように設計されています。 VRRPは、LAN上のVRRPルーターの1つに仮想ルーターの責任を動的に割り当てる選挙プロトコルを指定します。仮想ルーターに関連付けられたIPv4アドレスを制御するVRRPルーターはマスターと呼ばれ、送信されたパケットをこれらのIPv4アドレスに転送します。マスターが使用できなくなった場合、選定プロセスにより、転送の責任において動的なフェイルオーバーが提供されます。その後、LAN上の仮想ルーターのIPv4アドレスは、エンドホストによってデフォルトのファーストホップルーターとして使用できます。 VRRPを使用することで得られる利点は、すべてのエンドホストで動的ルーティングまたはルーター検出プロトコルを構成する必要がない、より高い可用性のデフォルトパスです。
IPv6 hosts on a LAN will usually learn about one or more default routers by receiving Router Advertisements sent using the IPv6 Neighbor Discovery (ND) protocol [RFC4861]. The Router Advertisements are multicast periodically at a rate that the hosts will learn about the default routers in a few minutes. They are not sent frequently enough to rely on the absence of the Router Advertisement to detect router failures.
通常、LAN上のIPv6ホストは、IPv6近隣探索（ND）プロトコル[RFC4861]を使用して送信されたルーターアドバタイズを受信することにより、1つ以上のデフォルトルーターについて学習します。ルーターアドバタイズは、ホストが数分でデフォルトルーターについて学習するレートで定期的にマルチキャストされます。これらは、ルーター障害を検出するためにルーターアドバタイズメントがないことに依存するほど頻繁には送信されません。
Neighbor Discovery (ND) includes a mechanism called Neighbor Unreachability Detection to detect the failure of a neighbor node (router or host) or the forwarding path to a neighbor. This is done by sending unicast ND Neighbor Solicitation messages to the neighbor node. To reduce the overhead of sending Neighbor Solicitations, they are only sent to neighbors to which the node is actively sending traffic and only after there has been no positive indication that the router is up for a period of time. Using the default parameters in ND, it will take a host about 38 seconds to learn that a router is unreachable before it will switch to another default router. This delay would be very noticeable to users and cause some transport protocol implementations to time out.
近隣探索（ND）には、近隣ノード（ルーターまたはホスト）または近隣への転送パスの障害を検出するための近隣到達不能検出と呼ばれるメカニズムが含まれています。これは、ユニキャストND近隣要請メッセージを近隣ノードに送信することによって行われます。近隣要請を送信するオーバーヘッドを削減するために、近隣要請は、ノードがトラフィックをアクティブに送信している近隣にのみ送信され、ルーターが一定時間稼働しているという明確な兆候がない場合にのみ送信されます。 NDのデフォルトパラメータを使用すると、ホストが別のデフォルトルータに切り替える前に、ルータが到達不能であることを学習するのに約38秒かかります。この遅延はユーザーには非常に顕著であり、一部のトランスポートプロトコル実装がタイムアウトする原因になります。
While the ND unreachability detection could be made quicker by changing the parameters to be more aggressive (note that the current lower limit for this is 5 seconds), this would have the downside of significantly increasing the overhead of ND traffic, especially when there are many hosts all trying to determine the reachability of one of more routers.
パラメータをより積極的に変更することでND到達不能検出をより速くすることができますが（これの現在の下限は5秒であることに注意してください）、これには、特にNDトラフィックのオーバーヘッドが大幅に増加するという欠点があります。ホストはすべて、1つ以上のルーターの到達可能性を判別しようとします。
The Virtual Router Redundancy Protocol for IPv6 provides a much faster switchover to an alternate default router than can be obtained using standard ND procedures. Using VRRP, a Backup router can take over for a failed default router in around three seconds (using VRRP default parameters). This is done without any interaction with the hosts and a minimum amount of VRRP traffic.
IPv6の仮想ルーター冗長プロトコルは、標準のND手順を使用して取得できるよりもはるかに高速な代替デフォルトルーターへの切り替えを提供します。 VRRPを使用すると、バックアップルータは障害が発生したデフォルトルータを約3秒で引き継ぐことができます（VRRPデフォルトパラメータを使用）。これは、ホストとの対話や最小量のVRRPトラフィックなしで行われます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The remainder of this document describes the features, design goals, and theory of operation of VRRP. The message formats, protocol processing rules, and state machine that guarantee convergence to a single Virtual Router Master are presented. Finally, operational issues related to MAC address mapping, handling of ARP requests, generation of ICMP redirect messages, and security issues are addressed.
このドキュメントの残りの部分では、VRRPの機能、設計目標、および動作理論について説明します。単一の仮想ルーターマスターへの収束を保証するメッセージ形式、プロトコル処理ルール、およびステートマシンが提示されます。最後に、MACアドレスマッピング、ARP要求の処理、ICMPリダイレクトメッセージの生成、およびセキュリティの問題に関連する運用上の問題について説明します。
VRRP Router A router running the Virtual Router Redundancy Protocol. It may participate as one or more virtual routers.
VRRPルーター仮想ルーター冗長プロトコルを実行するルーター。 1つ以上の仮想ルーターとして参加できます。
Virtual Router An abstract object managed by VRRP that acts as a default router for hosts on a shared LAN. It consists of a Virtual Router Identifier and either a set of associated IPv4 addresses or a set of associated IPv6 addresses across a common LAN. A VRRP Router may back up one or more virtual routers.
仮想ルーターVRRPによって管理される抽象オブジェクトで、共有LAN上のホストのデフォルトルーターとして機能します。これは、仮想ルーターIDと、関連するIPv4アドレスのセットまたは共通のLAN上の関連するIPv6アドレスのセットで構成されます。 VRRPルーターは、1つ以上の仮想ルーターをバックアップできます。
IP Address Owner The VRRP router that has the virtual router's IPvX address(es) as real interface address(es). This is the router that, when up, will respond to packets addressed to one of these IPvX addresses for ICMP pings, TCP connections, etc.
IPアドレスの所有者仮想ルーターのIPvXアドレスを実際のインターフェースアドレスとして持つVRRPルーター。これはルータであり、起動すると、ICMP ping、TCP接続などのこれらのIPvXアドレスの1つにアドレス指定されたパケットに応答します。
Primary IP Address In IPv4, an IPv4 address selected from the set of real interface addresses. One possible selection algorithm is to always select the first address. In IPv4 mode, VRRP advertisements are always sent using the primary IPv4 address as the source of the IPv4 packet. In IPv6, the link-local address of the interface over which the packet is transmitted is used.
プライマリIPアドレスIPv4では、実際のインターフェイスアドレスのセットから選択されたIPv4アドレス。可能な選択アルゴリズムの1つは、常に最初のアドレスを選択することです。 IPv4モードでは、VRRPアドバタイズメントは常にIPv4パケットのソースとしてプライマリIPv4アドレスを使用して送信されます。 IPv6では、パケットが送信されるインターフェイスのリンクローカルアドレスが使用されます。
Virtual Router Master The VRRP router that is assuming the responsibility of forwarding packets sent to the IPvX address(es) associated with the virtual router, answering ARP requests for the IPv4 address(es), and answering ND requests for the IPv6 address(es). Note that if the IPvX address owner is available, then it will always become the Master.
仮想ルーターマスター仮想ルーターに関連付けられたIPvXアドレスに送信されたパケットの転送、IPv4アドレスへのARP要求への応答、およびIPv6アドレスへのND要求への応答を担当するVRRPルーター。 IPvXアドレスの所有者が利用可能な場合、それは常にマスターになります。
Virtual Router Backup The set of VRRP routers available to assume forwarding responsibility for a virtual router should the current Master fail.
仮想ルーターのバックアップ現在のマスターに障害が発生した場合に、仮想ルーターの転送責任を負うために使用できるVRRPルーターのセット。
This section outlines the set of features that were considered mandatory and that guided the design of VRRP.
このセクションでは、必須と見なされ、VRRPの設計を導いた一連の機能の概要を説明します。
Backup of an IPvX address or addresses is the primary function of VRRP. While providing election of a Virtual Router Master and the additional functionality described below, the protocol should strive to:
IPvXアドレスのバックアップは、VRRPの主要な機能です。仮想ルーターマスターの選択と、以下で説明する追加機能を提供する一方で、プロトコルは次のように努力する必要があります。
o Minimize the duration of black holes.
o ブラックホールの期間を最小限に抑えます。
o Minimize the steady-state bandwidth overhead and processing complexity.
o 定常状態の帯域幅のオーバーヘッドと処理の複雑さを最小限に抑えます。
o Function over a wide variety of multiaccess LAN technologies capable of supporting IPvX traffic.
o IPvXトラフィックをサポートできるさまざまなマルチアクセスLANテクノロジーを介して機能します。
o Allow multiple virtual routers on a network for load balancing.
o 負荷分散のためにネットワーク上の複数の仮想ルーターを許可します。
o Support multiple logical IPvX subnets on a single LAN segment.
o 単一のLANセグメントで複数の論理IPvXサブネットをサポートします。
A simple model of Master election among a set of redundant routers is to treat each router with equal preference and claim victory after converging to any router as Master. However, there are likely to be many environments where there is a distinct preference (or range of preferences) among the set of redundant routers. For example, this preference may be based upon access link cost or speed, router performance or reliability, or other policy considerations. The protocol should allow the expression of this relative path preference in an intuitive manner and guarantee Master convergence to the most preferential router currently available.
一連の冗長ルーター間でのマスター選出の単純なモデルは、各ルーターを同じ優先度で扱い、マスターとしてルーターに収束した後に勝利を主張することです。ただし、冗長ルーターのセットの間に明確な優先順位（または一連の優先順位）が存在する多くの環境が存在する可能性があります。たとえば、この設定は、アクセスリンクのコストまたは速度、ルーターのパフォーマンスまたは信頼性、またはその他のポリシーの考慮事項に基づく場合があります。プロトコルは、この相対パス設定を直感的な方法で表現できるようにし、マスターが現在利用可能な最も優先度の高いルーターに収束することを保証する必要があります。
Once Master election has been performed, any unnecessary transitions between Master and Backup routers can result in a disruption in service. The protocol should ensure after Master election that no state transition is triggered by any Backup router of equal or lower preference as long as the Master continues to function properly.
マスターの選択が行われると、マスターとバックアップのルーター間の不要な移行により、サービスが中断する可能性があります。プロトコルは、マスターの選択後、マスターが適切に機能し続ける限り、優先順位が同じかそれより低いバックアップルータによって状態遷移がトリガーされないようにする必要があります。
Some environments may find it beneficial to avoid the state transition triggered when a router that is preferred over the current Master becomes available. It may be useful to support an override of the immediate convergence to the preferred path.
一部の環境では、現在のマスターよりも優先されるルーターが使用可能になったときにトリガーされる状態遷移を回避することが有益である場合があります。優先パスへの即時収束のオーバーライドをサポートすると役立つ場合があります。
Sending IPvX packets (that is, sending either IPv4 or IPv6) on a multiaccess LAN requires mapping from an IPvX address to a MAC address. The use of the virtual router MAC address in an extended LAN employing learning bridges can have a significant effect on the bandwidth overhead of packets sent to the virtual router. If the virtual router MAC address is never used as the source address in a link-level frame, then the station location is never learned, resulting in flooding of all packets sent to the virtual router. To improve the efficiency in this environment, the protocol should: 1) use the virtual router MAC address as the source in a packet sent by the Master to trigger station learning; 2) trigger a message immediately after transitioning to the Master to update the station learning; and 3) trigger periodic messages from the Master to maintain the station learning cache.
マルチアクセスLANでIPvXパケットを送信する（つまり、IPv4またはIPv6を送信する）には、IPvXアドレスからMACアドレスへのマッピングが必要です。ラーニングブリッジを使用する拡張LANで仮想ルーターのMACアドレスを使用すると、仮想ルーターに送信されるパケットの帯域幅オーバーヘッドに大きな影響を与える可能性があります。仮想ルーターのMACアドレスがリンクレベルフレームの送信元アドレスとして使用されない場合、ステーションの場所は学習されないため、仮想ルーターに送信されるすべてのパケットがフラッディングします。この環境で効率を改善するには、プロトコルで次のことを行う必要があります。1）マスターが送信するパケットのソースとして仮想ルーターのMACアドレスを使用して、ステーションの学習をトリガーします。 2）マスターに移行した直後にメッセージをトリガーして、ステーションの学習を更新します。 3）マスターからの定期的なメッセージをトリガーして、ステーションの学習キャッシュを維持します。
Sub-second detection of Master VRRP router failure is needed in both IPv4 and IPv6 environments. Earlier work proposed that sub-second operation was for IPv6; this specification leverages that earlier approach for IPv4 and IPv6.
IPv4とIPv6の両方の環境で、マスターVRRPルーター障害の1秒未満の検出が必要です。以前の研究では、1秒未満の操作はIPv6向けであると提案されていました。この仕様は、IPv4とIPv6に対する以前のアプローチを活用しています。
One possible problematic scenario when using small VRRP_Advertisement_Intervals may occur when a router is delivering more packets onto the LAN than can be accommodated, and so a queue builds up in the router. It is possible that packets being transmitted onto the VRRP-protected LAN could see larger queueing delay than the smallest VRRP Advertisement_Interval. In this case, the Master_Down_Interval will be small enough so that normal queuing delays might cause a VRRP Backup to conclude that the Master is down, and therefore promote itself to Master. Very shortly afterwards, the delayed VRRP packets from the Master cause a switch back to Backup status. Furthermore, this process can repeat many times per second, causing significant disruption to traffic. To mitigate this problem, priority forwarding of VRRP packets should be considered. It should be possible for a VRRP Master to observe that this situation is occurring frequently and at least log the problem.
小さなVRRP_Advertisement_Intervalsを使用する場合に問題となる可能性のあるシナリオの1つは、ルーターが収容できるよりも多くのパケットをLANに配信しているために、キューがルーターに蓄積する場合です。 VRRPで保護されたLANに送信されるパケットでは、最小のVRRP Advertisement_Intervalよりも大きなキューイング遅延が発生する可能性があります。この場合、Master_Down_Intervalは十分に小さいため、通常のキューイング遅延により、VRRPバックアップはマスターがダウンしていると判断し、マスターに昇格する可能性があります。そのすぐ後、マスターからの遅延VRRPパケットにより、バックアップステータスに戻ります。さらに、このプロセスは1秒あたり何回も繰り返す可能性があり、トラフィックに重大な混乱を引き起こします。この問題を軽減するには、VRRPパケットの優先転送を検討する必要があります。 VRRPマスターは、この状況が頻繁に発生していることを観察し、少なくとも問題をログに記録できるはずです。
VRRP specifies an election protocol to provide the virtual router function described earlier. All protocol messaging is performed using either IPv4 or IPv6 multicast datagrams; thus, the protocol can operate over a variety of multiaccess LAN technologies supporting IPvX multicast. Each link of a VRRP virtual router has a single well-known MAC address allocated to it. This document currently only details the mapping to networks using the IEEE 802 48-bit MAC address. The virtual router MAC address is used as the source in all periodic VRRP messages sent by the Master router to enable bridge learning in an extended LAN.
VRRPは、前述の仮想ルーター機能を提供するための選択プロトコルを指定します。すべてのプロトコルメッセージングは、IPv4またはIPv6マルチキャストデータグラムを使用して実行されます。したがって、プロトコルは、IPvXマルチキャストをサポートするさまざまなマルチアクセスLANテクノロジー上で動作できます。 VRRP仮想ルーターの各リンクには、1つの既知のMACアドレスが割り当てられています。このドキュメントでは現在、IEEE 802 48ビットMACアドレスを使用するネットワークへのマッピングについてのみ詳しく説明しています。仮想ルーターのMACアドレスは、マスタールーターによって送信されるすべての定期的なVRRPメッセージのソースとして使用され、拡張LANでブリッジラーニングを有効にします。
A virtual router is defined by its virtual router identifier (VRID) and a set of either IPv4 or IPv6 address(es). A VRRP router may associate a virtual router with its real address on an interface. The scope of each virtual router is restricted to a single LAN. A VRRP router may be configured with additional virtual router mappings and priority for virtual routers it is willing to back up. The mapping between the VRID and its IPvX address(es) must be coordinated among all VRRP routers on a LAN.
仮想ルーターは、その仮想ルーター識別子（VRID）とIPv4またはIPv6アドレスのセットで定義されます。 VRRPルーターは、仮想ルーターをインターフェイス上の実際のアドレスに関連付ける場合があります。各仮想ルーターのスコープは、単一のLANに制限されています。 VRRPルーターは、追加の仮想ルーターマッピングと、バックアップしたい仮想ルーターの優先度を使用して構成できます。 VRIDとそのIPvXアドレス間のマッピングは、LAN上のすべてのVRRPルーター間で調整する必要があります。
There is no restriction against reusing a VRID with a different address mapping on different LANs, nor is there a restriction against using the same VRID number for a set of IPv4 addresses and a set of IPv6 addresses; however, these are two different virtual routers.
異なるLANで異なるアドレスマッピングでVRIDを再利用することに対する制限はなく、IPv4アドレスのセットとIPv6アドレスのセットに同じVRID番号を使用することに対する制限もありません。ただし、これらは2つの異なる仮想ルーターです。
To minimize network traffic, only the Master for each virtual router sends periodic VRRP Advertisement messages. A Backup router will not attempt to preempt the Master unless it has higher priority. This eliminates service disruption unless a more preferred path becomes available. It's also possible to administratively prohibit all preemption attempts. The only exception is that a VRRP router will always become Master of any virtual router associated with addresses it owns. If the Master becomes unavailable, then the highest-priority Backup will transition to Master after a short delay, providing a controlled transition of the virtual router responsibility with minimal service interruption.
ネットワークトラフィックを最小限に抑えるために、各仮想ルーターのマスターのみが定期的にVRRPアドバタイズメッセージを送信します。バックアップルーターは、マスターの優先度が高い場合を除き、マスターを優先使用しません。これにより、より優先されるパスが使用可能にならない限り、サービスの中断がなくなります。すべてのプリエンプション試行を管理上禁止することもできます。唯一の例外は、VRRPルーターは常に、自身が所有するアドレスに関連付けられた仮想ルーターのマスターになることです。マスターが使用できなくなると、優先度の最も高いバックアップが少し遅れてマスターに移行し、サービスの中断を最小限に抑えて仮想ルーターの責任を制御して移行します。
The VRRP protocol design provides rapid transition from Backup to Master to minimize service interruption and incorporates optimizations that reduce protocol complexity while guaranteeing controlled Master transition for typical operational scenarios. The optimizations result in an election protocol with minimal runtime state requirements, minimal active protocol states, and a single message type and sender. The typical operational scenarios are defined to be two redundant routers and/or distinct path preferences among each router. A side effect when these assumptions are violated (i.e., more than two redundant paths, all with equal preference) is that duplicate packets may be forwarded for a brief period during Master election. However, the typical scenario assumptions are likely to cover the vast majority of deployments, loss of the Master router is infrequent, and the expected duration in Master election convergence is quite small ( << 1 second ). Thus, the VRRP optimizations represent significant simplifications in the protocol design while incurring an insignificant probability of brief network degradation.
VRRPプロトコル設計は、バックアップからマスターへの迅速な移行を提供してサービスの中断を最小限に抑え、プロトコルの複雑さを軽減すると同時に、典型的な運用シナリオでのマスターの移行の制御を保証する最適化を組み込みます。最適化により、実行時状態の要件、アクティブなプロトコル状態、および単一のメッセージタイプと送信者が最小限の選挙プロトコルが得られます。典型的な運用シナリオは、2つの冗長ルーターおよび/または各ルーター間での異なるパス設定として定義されています。これらの仮定に違反した場合の副次的な影響（つまり、優先度がすべて同じである2つ以上の冗長パス）は、マスターの選択中に短い間、重複したパケットが転送される可能性があります。ただし、典型的なシナリオの想定は、展開の大部分をカバーする可能性が高く、マスタールーターの損失はまれであり、マスター選択の収束で予想される期間は非常に短い（<< 1秒）。したがって、VRRPの最適化は、プロトコルの設計を大幅に簡素化すると同時に、ネットワークが短時間で低下する可能性はわずかです。
The following figure shows a simple network with two VRRP routers implementing one virtual router.
次の図は、1つの仮想ルーターを実装する2つのVRRPルーターを持つ単純なネットワークを示しています。
+-----------+ +-----------+
| Rtr1 | | Rtr2 |
|(MR VRID=1)| |(BR VRID=1)|
| | | |
VRID=1 +-----------+ +-----------+
IPvX A--------->* *<---------IPvX B
| |
| |
----------------+------------+-----+----------+----------+----------+--
^ ^ ^ ^
| | | |
default rtr IPvX addrs-------> (IPvX A) (IPvX A) (IPvX A) (IPvX A)
| | | |
IPvX H1->* IpvX H2->* IPvX H3->* IpvX H4->*
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
Legend:
--+---+---+-- = Ethernet, Token Ring, or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IPvX Address; X is 4 everywhere in IPv4 case
X is 6 everywhere in IPv6 case
(IPvX) = default router for hosts
Eliminating all mention of VRRP (VRID=1) from the figure above leaves it as a typical deployment.
上の図からVRRP（VRID = 1）についての言及をすべて排除すると、それは典型的な展開のままになります。
In the IPv4 case (that is, IPvX is IPv4 everywhere in the figure), each router is permanently assigned an IPv4 address on the LAN interface (Rtr1 is assigned IPv4 A and Rtr2 is assigned IPv4 B), and each host installs a static default route through one of the routers (in this example they all use Rtr1's IPv4 A).
IPv4の場合（つまり、IPvXは図のどこでもIPv4です）、各ルーターにはLANインターフェイスでIPv4アドレスが永続的に割り当てられ（Rtr1にはIPv4 Aが割り当てられ、Rtr2にはIPv4 Bが割り当てられます）、各ホストは静的なデフォルトをインストールしますルーターの1つを経由してルーティングします（この例では、すべてRtr1のIPv4 Aを使用しています）。
In the IPv6 case (that is, IPvX is IPv6 everywhere in the figure), each router has a link-local IPv6 address on the LAN interface (Rtr1 is assigned IPv6 Link-Local A and Rtr2 is assigned IPv6 Link-Local B), and each host learns a default route from Router Advertisements through one of the routers (in this example, they all use Rtr1's IPv6 Link-Local A).
IPv6の場合（つまり、IPvXは図のどこでもIPv6です）、各ルーターはLANインターフェイスにリンクローカルIPv6アドレスを持っています（Rtr1にはIPv6リンクローカルAが割り当てられ、Rtr2にはIPv6リンクローカルBが割り当てられます）。また、各ホストはルーターアドバタイズからデフォルトルートを学習します（この例では、Rtr1のIPv6リンクローカルAを使用しています）。
Moving to an IPv4 VRRP environment, each router has the exact same permanently assigned IPv4 address. Rtr1 is said to be the IPv4 address owner of IPv4 A, and Rtr2 is the IPv4 address owner of IPv4 B. A virtual router is then defined by associating a unique identifier (the virtual router ID) with the address owned by a router.
IPv4 VRRP環境に移行すると、各ルーターには完全に同じ永久的に割り当てられたIPv4アドレスが割り当てられます。 Rtr1はIPv4 AのIPv4アドレス所有者であり、Rtr2はIPv4 BのIPv4アドレス所有者であると言われます。次に、一意の識別子（仮想ルーターID）をルーターが所有するアドレスに関連付けることにより、仮想ルーターが定義されます。
Moving to an IPv6 VRRP environment, each router has the exact same Link-Local IPv6 address. Rtr1 is said to be the IPv6 address owner of IPv6 A, and Rtr2 is the IPv6 address owner of IPv6 B. A virtual router is then defined by associating a unique identifier (the virtual router ID) with the address owned by a router.
IPv6 VRRP環境に移行すると、各ルーターはまったく同じリンクローカルIPv6アドレスを持ちます。 Rtr1はIPv6 AのIPv6アドレス所有者であり、Rtr2はIPv6 BのIPv6アドレス所有者であると言われます。次に、ルーターが所有するアドレスに一意の識別子（仮想ルーターID）を関連付けることにより、仮想ルーターが定義されます。
Finally, in both the IPv4 and IPv6 cases, the VRRP protocol manages virtual router failover to a Backup router.
最後に、IPv4とIPv6の両方の場合で、VRRPプロトコルはバックアップルーターへの仮想ルーターのフェールオーバーを管理します。
The IPv4 example above shows a virtual router configured to cover the IPv4 address owned by Rtr1 (VRID=1, IPv4_Address=A). When VRRP is enabled on Rtr1 for VRID=1, it will assert itself as Master, with priority = 255, since it is the IP address owner for the virtual router IP address. When VRRP is enabled on Rtr2 for VRID=1, it will transition to Backup, with priority = 100 (the default priority is 100), since it is not the IPv4 address owner. If Rtr1 should fail, then the VRRP protocol will transition Rtr2 to Master, temporarily taking over forwarding responsibility for IPv4 A to provide uninterrupted service to the hosts. When Rtr1 returns to service, it will re-assert itself as Master.
上記のIPv4の例は、Rtr1が所有するIPv4アドレス（VRID = 1、IPv4_Address = A）をカバーするように構成された仮想ルーターを示しています。 VRRPがVRID = 1のRtr1で有効になっている場合、VRRPは仮想ルーターIPアドレスのIPアドレス所有者であるため、優先度= 255でマスターとしてアサートされます。 VRRPは、VRID = 1のRtr2で有効になっている場合、IPv4アドレスの所有者ではないため、優先度= 100（デフォルトの優先度は100）でバックアップに移行します。 Rtr1に障害が発生した場合、VRRPプロトコルはRtr2をマスターに移行し、IPv4 Aの転送の責任を一時的に引き継いで、中断のないサービスをホストに提供します。 Rtr1がサービスに戻ると、マスターとして再びアサートします。
The IPv6 example above shows a virtual router configured to cover the IPv6 address owned by Rtr1 (VRID=1, IPv6_Address=A). When VRRP is enabled on Rtr1 for VRID=1, it will assert itself as Master, with priority = 255, since it is the IPv6 address owner for the virtual router IPv6 address. When VRRP is enabled on Rtr2 for VRID=1, it will transition to Backup, with priority = 100 (the default priority is 100), since it is not the IPv6 address owner. If Rtr1 should fail, then the VRRP protocol will transition Rtr2 to Master, temporarily taking over forwarding responsibility for IPv6 A to provide uninterrupted service to the hosts.
上記のIPv6の例は、Rtr1が所有するIPv6アドレス（VRID = 1、IPv6_Address = A）をカバーするように構成された仮想ルーターを示しています。 VRRP = 1のRtr1でVRRPが有効になっている場合、VRRPは仮想ルーターIPv6アドレスのIPv6アドレス所有者であるため、優先度= 255でマスターとしてアサートされます。 VRRPがRID2でVRID = 1に対して有効になっている場合、IPv6アドレスの所有者ではないため、優先度= 100（デフォルトの優先度は100）でバックアップに移行します。 Rtr1に障害が発生した場合、VRRPプロトコルはRtr2をマスターに移行し、IPv6 Aの転送の責任を一時的に引き継いで、中断のないサービスをホストに提供します。
Note that in both cases, in this example IPvX B is not backed up; it is only used by Rtr2 as its interface address. In order to back up IPvX B, a second virtual router must be configured. This is shown in the next section.
どちらの場合も、この例ではIPvX Bはバックアップされないことに注意してください。 Rtr2はそのインターフェイスアドレスとしてのみ使用します。 IPvX Bをバックアップするには、2番目の仮想ルーターを構成する必要があります。これについては、次のセクションで説明します。
The following figure shows a configuration with two virtual routers with the hosts splitting their traffic between them.
次の図は、ホスト間でトラフィックを分割する2つの仮想ルーターの構成を示しています。
+-----------+ +-----------+
| Rtr1 | | Rtr2 |
|(MR VRID=1)| |(BR VRID=1)|
|(BR VRID=2)| |(MR VRID=2)|
VRID=1 +-----------+ +-----------+ VRID=2
IPvX A -------->* *<---------- IPvX B
| |
| |
----------------+------------+-----+----------+----------+----------+--
^ ^ ^ ^
| | | |
default rtr IPvX addrs -----> (IPvX A) (IPvX A) (IPvX B) (IPvX B)
| | | |
IPvX H1->* IpvX H2->* IPvX H3->* IpvX H4->*
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
Legend:
---+---+---+-- = Ethernet, Token Ring, or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IPvX Address; X is 4 everywhere in IPv4 case
X is 6 everywhere in IPv6 case
(IPvX) = default router for hosts
In the IPv4 example above (that is, IPvX is IPv4 everywhere in the figure), half of the hosts have configured a static route through Rtr1's IPv4 A, and half are using Rtr2's IPv4 B. The configuration of virtual router VRID=1 is exactly the same as in the first example (see Section 4.1), and a second virtual router has been added to
上記のIPv4の例では（つまり、IPvXは図のどこでもIPv4です）、ホストの半分はRtr1のIPv4 Aを介して静的ルートを構成し、半分はRtr2のIPv4 Bを使用しています。仮想ルーターVRID = 1の構成は正確に最初の例と同じ（セクション4.1を参照）で、2番目の仮想ルーターが
cover the IPv4 address owned by Rtr2 (VRID=2, IPv4_Address=B). In this case, Rtr2 will assert itself as Master for VRID=2 while Rtr1 will act as a Backup. This scenario demonstrates a deployment providing load splitting when both routers are available, while providing full redundancy for robustness.
Rtr2が所有するIPv4アドレスをカバーします（VRID = 2、IPv4_Address = B）。この場合、Rtr2はVRID = 2のマスターとしてアサートされ、Rtr1はバックアップとして機能します。このシナリオは、両方のルーターが利用可能な場合に負荷を分割しながら、堅牢性のための完全な冗長性を提供する配備を示しています。
In the IPv6 example above (that is, IPvX is IPv6 everywhere in the figure), half of the hosts have learned a default route through Rtr1's IPv6 A, and half are using Rtr2's IPv6 B. The configuration of virtual router VRID=1 is exactly the same as in the first example (see Section 4.1), and a second virtual router has been added to cover the IPv6 address owned by Rtr2 (VRID=2, IPv6_Address=B). In this case, Rtr2 will assert itself as Master for VRID=2 while Rtr1 will act as a Backup. This scenario demonstrates a deployment providing load splitting when both routers are available, while providing full redundancy for robustness.
上記のIPv6の例では（つまり、IPvXは図のどこでもIPv6です）、ホストの半分はRtr1のIPv6 Aを介してデフォルトルートを学習し、半分はRtr2のIPv6 Bを使用しています。仮想ルーターVRID = 1の構成は正確に最初の例と同じ（セクション4.1を参照）。Rtr2が所有するIPv6アドレス（VRID = 2、IPv6_Address = B）をカバーするために2番目の仮想ルーターが追加されました。この場合、Rtr2はVRID = 2のマスターとしてアサートされ、Rtr1はバックアップとして機能します。このシナリオは、両方のルーターが利用可能な場合に負荷を分割しながら、堅牢性のための完全な冗長性を提供する配備を示しています。
Note that the details of load balancing are out of scope of this document. However, in a case where the servers need different weights, it may not make sense to rely on router advertisements alone to balance the host load between the routers.
負荷分散の詳細はこのドキュメントの範囲外であることに注意してください。ただし、サーバーに異なる重みが必要な場合は、ルーターアドバタイズのみに依存してルーター間のホスト負荷のバランスを取ることは意味がない場合があります。
The purpose of the VRRP packet is to communicate to all VRRP routers the priority and the state of the Master router associated with the VRID.
VRRPパケットの目的は、VRIDに関連付けられたマスタールーターの優先度と状態をすべてのVRRPルーターと通信することです。
When VRRP is protecting an IPv4 address, VRRP packets are sent encapsulated in IPv4 packets. They are sent to the IPv4 multicast address assigned to VRRP.
VRRPがIPv4アドレスを保護している場合、VRRPパケットはIPv4パケットにカプセル化されて送信されます。それらはVRRPに割り当てられたIPv4マルチキャストアドレスに送信されます。
When VRRP is protecting an IPv6 address, VRRP packets are sent encapsulated in IPv6 packets. They are sent to the IPv6 multicast address assigned to VRRP.
VRRPがIPv6アドレスを保護している場合、VRRPパケットはIPv6パケットにカプセル化されて送信されます。それらは、VRRPに割り当てられたIPv6マルチキャストアドレスに送信されます。
This section defines the format of the VRRP packet and the relevant fields in the IP header.
このセクションでは、VRRPパケットのフォーマットとIPヘッダーの関連フィールドを定義します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Fields or IPv6 Fields |
... ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|(rsvd) | Max Adver Int | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPvX Address(es) |
+ +
+ +
+ +
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the primary IPv4 address of the interface the packet is being sent from.
これは、パケットの送信元であるインターフェースのプライマリIPv4アドレスです。
The IPv4 multicast address as assigned by the IANA for VRRP is:
IRPがVRRPに割り当てるIPv4マルチキャストアドレスは次のとおりです。
224.0.0.18
２２４。０。０。１８
This is a link-local scope multicast address. Routers MUST NOT forward a datagram with this destination address, regardless of its TTL.
これはリンクローカルスコープのマルチキャストアドレスです。ルーターは、TTLに関係なく、この宛先アドレスでデータグラムを転送してはなりません（MUST NOT）。
The TTL MUST be set to 255. A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet.
TTLは255に設定する必要があります。255以外のTTLでパケットを受信するVRRPルーターは、パケットを破棄する必要があります。
The IPv4 protocol number assigned by the IANA for VRRP is 112 (decimal).
IRPがVRRPに割り当てるIPv4プロトコル番号は112（10進数）です。
This is the IPv6 link-local address of the interface the packet is being sent from.
これは、パケットの送信元であるインターフェイスのIPv6リンクローカルアドレスです。
The IPv6 multicast address assigned by the IANA for VRRP is:
IRPがVRRPに割り当てるIPv6マルチキャストアドレスは次のとおりです。
FF02:0:0:0:0:0:0:12
This is a link-local scope multicast address. Routers MUST NOT forward a datagram with this destination address, regardless of its Hop Limit.
これはリンクローカルスコープのマルチキャストアドレスです。ルーターは、ホップ制限に関係なく、この宛先アドレスでデータグラムを転送してはなりません（MUST NOT）。
The Hop Limit MUST be set to 255. A VRRP router receiving a packet with the Hop Limit not equal to 255 MUST discard the packet.
ホップ制限は255に設定する必要があります。ホップ制限が255でないパケットを受信するVRRPルーターは、パケットを破棄する必要があります。
The IPv6 Next Header protocol assigned by the IANA for VRRP is 112 (decimal).
IRPがVRRPに割り当てるIPv6 Next Headerプロトコルは112（10進数）です。
The version field specifies the VRRP protocol version of this packet. This document defines version 3.
versionフィールドは、このパケットのVRRPプロトコルバージョンを指定します。このドキュメントはバージョン3を定義します。
The type field specifies the type of this VRRP packet. The only packet type defined in this version of the protocol is:
タイプフィールドは、このVRRPパケットのタイプを指定します。このバージョンのプロトコルで定義されている唯一のパケットタイプは次のとおりです。
1 ADVERTISEMENT
1広告
A packet with unknown type MUST be discarded.
不明なタイプのパケットは破棄しなければなりません（MUST）。
The Virtual Rtr ID field identifies the virtual router this packet is reporting status for.
Virtual Rtr IDフィールドは、このパケットがステータスを報告している仮想ルーターを識別します。
The priority field specifies the sending VRRP router's priority for the virtual router. Higher values equal higher priority. This field is an 8-bit unsigned integer field.
優先度フィールドは、仮想ルーターに対する送信VRRPルーターの優先度を指定します。値が大きいほど優先度が高くなります。このフィールドは、8ビットの符号なし整数フィールドです。
The priority value for the VRRP router that owns the IPvX address associated with the virtual router MUST be 255 (decimal).
仮想ルーターに関連付けられたIPvXアドレスを所有するVRRPルーターの優先順位値は、255（10進数）でなければなりません。
VRRP routers backing up a virtual router MUST use priority values between 1-254 (decimal). The default priority value for VRRP routers backing up a virtual router is 100 (decimal).
仮想ルーターをバックアップするVRRPルーターは、1〜254（10進数）の優先順位値を使用する必要があります。仮想ルーターをバックアップするVRRPルーターのデフォルトの優先度値は100（10進数）です。
The priority value zero (0) has special meaning, indicating that the current Master has stopped participating in VRRP. This is used to trigger Backup routers to quickly transition to Master without having to wait for the current Master to time out.
プライオリティ値ゼロ（0）には特別な意味があり、現在のマスターがVRRPへの参加を停止したことを示します。これは、現在のマスターがタイムアウトするのを待たずにマスターにすばやく移行するようにバックアップルーターをトリガーするために使用されます。
This is the number of either IPv4 addresses or IPv6 addresses contained in this VRRP advertisement. The minimum value is 1.
これは、このVRRPアドバタイズメントに含まれるIPv4アドレスまたはIPv6アドレスの数です。最小値は1です。
This field MUST be set to zero on transmission and ignored on reception.
このフィールドは送信時にゼロに設定されなければならず、受信時には無視されなければなりません。
The Maximum Advertisement Interval is a 12-bit field that indicates the time interval (in centiseconds) between ADVERTISEMENTS. The default is 100 centiseconds (1 second).
最大広告間隔は、ADVERTISEMENTS間の時間間隔（センチ秒単位）を示す12ビットのフィールドです。デフォルトは100センチ秒（1秒）です。
Note that higher-priority Master routers with slower transmission rates than their Backup routers are unstable. This is because low-priority nodes configured to faster rates could come online and decide they should be Masters before they have heard anything from the higher-priority Master with a slower rate. When this happens, it is temporary: once the lower-priority node does hear from the higher-priority Master, it will relinquish mastership.
バックアップルーターよりも伝送速度が遅い優先度の高いマスタールーターは不安定であることに注意してください。これは、より高いレートに設定された優先度の低いノードがオンラインになり、より優先度の高いマスターから遅いレートで何かを聞く前に、マスターになる必要があると判断する可能性があるためです。これが発生した場合、それは一時的なものです。優先度の低いノードが優先度の高いマスターから応答を受け取ると、マスターシップを放棄します。
The checksum field is used to detect data corruption in the VRRP message.
チェックサムフィールドは、VRRPメッセージのデータ破損を検出するために使用されます。
The checksum is the 16-bit one's complement of the one's complement sum of the entire VRRP message starting with the version field and a "pseudo-header" as defined in Section 8.1 of [RFC2460]. The next header field in the "pseudo-header" should be set to 112 (decimal) for VRRP. For computing the checksum, the checksum field is set to zero. See RFC1071 for more detail [RFC1071].
チェックサムは、[RFC2460]のセクション8.1で定義されているバージョンフィールドと「疑似ヘッダー」で始まるVRRPメッセージ全体の1の補数の合計の16ビットの1の補数です。 VRRPの場合、「疑似ヘッダー」の次のヘッダーフィールドを112（10進数）に設定する必要があります。チェックサムを計算するために、チェックサムフィールドはゼロに設定されます。詳細については、RFC1071を参照してください[RFC1071]。
This refers to one or more IPvX addresses associated with the virtual router. The number of addresses included is specified in the "Count IP Addr" field. These fields are used for troubleshooting misconfigured routers. If more than one address is sent, it is recommended that all routers be configured to send these addresses in the same order to make it easier to do this comparison.
これは、仮想ルーターに関連付けられた1つ以上のIPvXアドレスを指します。含まれるアドレスの数は、「IPアドレスのカウント」フィールドで指定されます。これらのフィールドは、誤って構成されたルーターのトラブルシューティングに使用されます。複数のアドレスを送信する場合は、これらのアドレスを同じ順序で送信するようにすべてのルーターを構成して、この比較を容易にすることをお勧めします。
For IPv4 addresses, this refers to one or more IPv4 addresses that are backed up by the virtual router.
IPv4アドレスの場合、これは仮想ルーターによってバックアップされる1つ以上のIPv4アドレスを指します。
For IPv6, the first address must be the IPv6 link-local address associated with the virtual router.
IPv6の場合、最初のアドレスは、仮想ルーターに関連付けられたIPv6リンクローカルアドレスである必要があります。
This field contains either one or more IPv4 addresses, or one or more IPv6 addresses, that is, IPv4 and IPv6 MUST NOT both be carried in one IPvX Address field.
このフィールドには、1つ以上のIPv4アドレス、または1つ以上のIPv6アドレスが含まれます。つまり、IPv4とIPv6の両方を1つのIPvXアドレスフィールドに含めることはできません。
VRID Virtual Router Identifier. Configurable item in the range 1-255 (decimal). There is no default.
VRID仮想ルーター識別子。 1から255（10進数）の範囲で構成可能なアイテム。デフォルトはありません。
Priority Priority value to be used by this VRRP router in Master election for this virtual router. The value of 255 (decimal) is reserved for the router that owns the IPvX address associated with the virtual router. The value of 0 (zero) is reserved for the Master router to indicate it is releasing responsibility for the virtual router. The range 1-254 (decimal) is available for VRRP routers backing up the virtual router. Higher values indicate higher priorities. The default value is 100 (decimal).
このVRRPルーターがこの仮想ルーターのマスター選択で使用する優先度の値。 255（10進数）の値は、仮想ルーターに関連付けられたIPvXアドレスを所有するルーター用に予約されています。値0（ゼロ）は、マスタールーターが仮想ルーターの責任を解放していることを示すために予約されています。仮想ルーターをバックアップするVRRPルーターでは、範囲1-254（10進数）を使用できます。値が大きいほど優先順位が高くなります。デフォルト値は100（10進数）です。
IPv4_Addresses One or more IPv4 addresses associated with this virtual router. Configured item with no default.
IPv4_Addressesこの仮想ルーターに関連付けられた1つ以上のIPv4アドレス。デフォルトなしの構成アイテム。
IPv6_Addresses One or more IPv6 addresses associated with this virtual router. Configured item with no default. The first address must be the Link-Local address associated with the virtual router.
IPv6_Addressesこの仮想ルーターに関連付けられた1つ以上のIPv6アドレス。デフォルトなしの構成アイテム。最初のアドレスは、仮想ルーターに関連付けられたリンクローカルアドレスである必要があります。
Advertisement_Interval Time interval between ADVERTISEMENTS (centiseconds). Default is 100 centiseconds (1 second).
Advertisement_Interval ADVERTISEMENTS間の時間間隔（センチ秒）。デフォルトは100センチ秒（1秒）です。
Master_Adver_Interval Advertisement interval contained in ADVERTISEMENTS received from the Master (centiseconds). This value is saved by virtual routers in the Backup state and used to compute Skew_Time and Master_Down_Interval. The initial value is the same as Advertisement_Interval.
Master_Adver_Intervalマスターから受信したADVERTISEMENTSに含まれる広告間隔（センチ秒）。この値は、バックアップ状態の仮想ルーターによって保存され、Skew_TimeおよびMaster_Down_Intervalの計算に使用されます。初期値はAdvertisement_Intervalと同じです。
Skew_Time Time to skew Master_Down_Interval in centiseconds. Calculated as
Skew_Time Master_Down_Intervalをスキューする時間（センチ秒）。として計算
(((256 - priority) * Master_Adver_Interval) / 256)
Master_Down_Interval Time interval for Backup to declare Master down (centiseconds). Calculated as
Master_Down_Interval Backupがマスターのダウンを宣言する時間間隔（センチ秒）。として計算
(3 * Master_Adver_Interval) + Skew_time
（3 * Master_Adver_Interval）+ Skew_time
Preempt_Mode Controls whether a (starting or restarting) higher-priority Backup router preempts a lower-priority Master router. Values are True to allow preemption and False to prohibit preemption. Default is True.
Preempt_Mode（起動または再起動）優先度の高いバックアップルーターが優先度の低いマスタールーターを優先するかどうかを制御します。値は、プリエンプションを許可する場合はTrue、プリエンプションを禁止する場合はFalseです。デフォルトはTrueです。
Note: The exception is that the router that owns the IPvX address associated with the virtual router always preempts, independent of the setting of this flag.
注：例外は、このフラグの設定に関係なく、仮想ルーターに関連付けられたIPvXアドレスを所有するルーターが常にプリエンプトすることです。
Accept_Mode Controls whether a virtual router in Master state will accept packets addressed to the address owner's IPvX address as its own if it is not the IPvX address owner. The default is False. Deployments that rely on, for example, pinging the address owner's IPvX address may wish to configure Accept_Mode to True.
Accept_Modeマスター状態の仮想ルーターが、IPvXアドレス所有者でない場合に、アドレス所有者のIPvXアドレス宛てのパケットをそれ自身のものとして受け入れるかどうかを制御します。デフォルトはFalseです。たとえば、アドレス所有者のIPvXアドレスへのpingに依存する展開では、Accept_ModeをTrueに構成する必要がある場合があります。
Note: IPv6 Neighbor Solicitations and Neighbor Advertisements MUST NOT be dropped when Accept_Mode is False.
注：Accept_ModeがFalseの場合、IPv6ネイバー請求およびネイバーアドバタイズメントはドロップしないでください。
Virtual_Router_MAC_Address The MAC address used for the source MAC address in VRRP advertisements and advertised in ARP responses as the MAC address to use for IP_Addresses.
Virtual_Router_MAC_Address VRRPアドバタイズメントの送信元MACアドレスに使用され、ARP応答でIP_Addressesに使用するMACアドレスとしてアドバタイズされるMACアドレス。
Master_Down_Timer Timer that fires when ADVERTISEMENT has not been heard for Master_Down_Interval.
Master_Down_Timer ADVERTISEMENTがMaster_Down_Intervalの間聞こえなかったときに起動するタイマー。
Adver_Timer Timer that fires to trigger sending of ADVERTISEMENT based on Advertisement_Interval.
Adverisement Intervalに基づいてADVERTISEMENTの送信をトリガーするために起動するAdver_Timerタイマー。
+---------------+
+--------->| |<-------------+
| | Initialize | |
| +------| |----------+ |
| | +---------------+ | |
| | | |
| V V |
+---------------+ +---------------+
| |---------------------->| |
| Master | | Backup |
| |<----------------------| |
+---------------+ +---------------+
In the state descriptions below, the state names are identified by {state-name}, and the packets are identified by all-uppercase characters.
以下の状態の説明では、状態名は{state-name}で識別され、パケットはすべて大文字で識別されます。
A VRRP router implements an instance of the state machine for each virtual router election it is participating in.
VRRPルーターは、参加している仮想ルーターの選択ごとに、状態マシンのインスタンスを実装します。
The purpose of this state is to wait for a Startup event, that is, an implementation-defined mechanism that initiates the protocol once it has been configured. The configuration mechanism is out of scope of this specification.
この状態の目的は、スタートアップイベント、つまり、プロトコルが構成されたらプロトコルを開始する実装定義のメカニズムを待つことです。構成メカニズムはこの仕様の範囲外です。
(100) If a Startup event is received, then:
（100）スタートアップイベントを受信した場合：
(105) - If the Priority = 255 (i.e., the router owns the IPvX address associated with the virtual router), then:
（105）-優先度= 255（つまり、ルーターが仮想ルーターに関連付けられたIPvXアドレスを所有している）の場合：
(110) + Send an ADVERTISEMENT
（110）+広告を送信
(115) + If the protected IPvX address is an IPv4 address, then:
（115）+保護されたIPvXアドレスがIPv4アドレスの場合：
(120) * Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router.
（120）*仮想ルーターに関連付けられた各IPアドレスの仮想ルーターMACアドレスを含む無償のARP要求をブロードキャストします。
(125) + else // IPv6
(130) * For each IPv6 address associated with the virtual router, send an unsolicited ND Neighbor Advertisement with the Router Flag (R) set, the Solicited Flag (S) unset, the Override flag (O) set, the target address set to the IPv6 address of the virtual router, and the target link-layer address set to the virtual router MAC address.
（130）*仮想ルーターに関連付けられたIPv6アドレスごとに、ルーターフラグ（R）セット、非請求フラグ（S）未設定、オーバーライドフラグ（O）セット、ターゲットアドレスセットを使用して、非請求NDネイバーアドバタイズを送信します。仮想ルーターのIPv6アドレス、および仮想ルーターのMACアドレスに設定されたターゲットリンク層アドレス。
(135) +endif // was protected addr IPv4?
(140) + Set the Adver_Timer to Advertisement_Interval
（140）+ Adver_TimerをAdvertisement_Intervalに設定します
(145) + Transition to the {Master} state
(150) - else // rtr does not own virt addr
(155) + Set Master_Adver_Interval to Advertisement_Interval
（155）+ Master_Adver_IntervalをAdvertisement_Intervalに設定
(160) + Set the Master_Down_Timer to Master_Down_Interval
（160）+ Master_Down_TimerをMaster_Down_Intervalに設定します
(165) + Transition to the {Backup} state
(170) -endif // priority was not 255
(175) endif // startup event was recv
（175）endif //起動イベントはrecvでした
The purpose of the {Backup} state is to monitor the availability and state of the Master router.
{Backup}状態の目的は、マスタールーターの可用性と状態を監視することです。
(300) While in this state, a VRRP router MUST do the following:
（300）この状態では、VRRPルーターは次のことを実行する必要があります。
(305) - If the protected IPvX address is an IPv4 address, then:
（305）-保護されたIPvXアドレスがIPv4アドレスの場合：
(310) + MUST NOT respond to ARP requests for the IPv4 address(es) associated with the virtual router.
（310）+仮想ルーターに関連付けられたIPv4アドレスのARP要求に応答してはならない（MUST NOT）。
(315) - else // protected addr is IPv6
(320) + MUST NOT respond to ND Neighbor Solicitation messages for the IPv6 address(es) associated with the virtual router.
（320）+仮想ルーターに関連付けられたIPv6アドレスのND近隣要請メッセージに応答してはならない（MUST NOT）。
(325) + MUST NOT send ND Router Advertisement messages for the virtual router.
（325）+仮想ルーターにNDルーター通知メッセージを送信してはならない（MUST NOT）。
(330) -endif // was protected addr IPv4?
(335) - MUST discard packets with a destination link-layer MAC address equal to the virtual router MAC address.
（335）-仮想ルーターのMACアドレスと等しい宛先リンク層MACアドレスを持つパケットを破棄する必要があります。
(340) - MUST NOT accept packets addressed to the IPvX address(es) associated with the virtual router.
（340）-仮想ルーターに関連付けられたIPvXアドレス宛のパケットを受け入れてはならない（MUST NOT）。
(345) - If a Shutdown event is received, then:
（345）-シャットダウンイベントを受信した場合：
(350) + Cancel the Master_Down_Timer
（350）+ Master_Down_Timerをキャンセルする
(355) + Transition to the {Initialize} state
(360) -endif // shutdown recv
(365) - If the Master_Down_Timer fires, then:
（365）-Master_Down_Timerが発生した場合：
(370) + Send an ADVERTISEMENT
（370）+広告を送信
(375) + If the protected IPvX address is an IPv4 address, then:
（375）+保護されたIPvXアドレスがIPv4アドレスの場合：
(380) * Broadcast a gratuitous ARP request on that interface containing the virtual router MAC address for each IPv4 address associated with the virtual router.
（380）*仮想ルーターに関連付けられた各IPv4アドレスの仮想ルーターMACアドレスを含む、そのインターフェースで無償のARP要求をブロードキャストします。
(385) + else // ipv6
(390) * Compute and join the Solicited-Node multicast address [RFC4291] for the IPv6 address(es) associated with the virtual router.
（390）*仮想ルーターに関連付けられたIPv6アドレスの要請ノードマルチキャストアドレス[RFC4291]を計算して参加させる。
(395) * For each IPv6 address associated with the virtual router, send an unsolicited ND Neighbor Advertisement with the Router Flag (R) set, the Solicited Flag (S) unset, the Override flag (O) set, the target address set to the IPv6 address of the virtual router, and the target link-layer address set to the virtual router MAC address.
（395）*仮想ルーターに関連付けられているIPv6アドレスごとに、ルーターフラグ（R）セット、非請求フラグ（S）未設定、オーバーライドフラグ（O）セット、ターゲットアドレスセットを使用して、非請求NDネイバーアドバタイズを送信します。仮想ルーターのIPv6アドレス、および仮想ルーターのMACアドレスに設定されたターゲットリンク層アドレス。
(400) +endif // was protected addr ipv4?
(405) + Set the Adver_Timer to Advertisement_Interval
（405）+ Adver_TimerをAdvertisement_Intervalに設定
(410) + Transition to the {Master} state
(415) -endif // Master_Down_Timer fired
(420) - If an ADVERTISEMENT is received, then:
（420）-ADVERTISEMENTを受け取った場合：
(425) + If the Priority in the ADVERTISEMENT is zero, then:
（425）+ ADVERTISEMENTの優先度がゼロの場合：
(430) * Set the Master_Down_Timer to Skew_Time
（430）* Master_Down_TimerをSkew_Timeに設定します
(440) + else // priority non-zero
(445) * If Preempt_Mode is False, or if the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then:
（445）* Preempt_ModeがFalseの場合、またはADVERTISEMENTの優先度がローカルの優先度以上の場合、次のようになります。
(450) @ Set Master_Adver_Interval to Adver Interval contained in the ADVERTISEMENT
（450）@ Master_Adver_IntervalをADVERTISEMENTに含まれるAdver Intervalに設定
(455) @ Recompute the Master_Down_Interval
（455）@ Master_Down_Intervalを再計算します
(460) @ Reset the Master_Down_Timer to Master_Down_Interval
（460）@ Master_Down_TimerをMaster_Down_Intervalにリセットする
(465) * else // preempt was true or priority was less
(470) @ Discard the ADVERTISEMENT
（470）@広告を破棄
(475) *endif // preempt test
(480) +endif // was priority zero?
(485) -endif // was advertisement recv?
(490) endwhile // Backup state
（490）endwhile //バックアップ状態
While in the {Master} state, the router functions as the forwarding router for the IPvX address(es) associated with the virtual router.
{Master}状態のとき、ルーターは仮想ルーターに関連付けられたIPvXアドレスの転送ルーターとして機能します。
Note that in the Master state, the Preempt_Mode Flag is not considered.
マスター状態では、Preempt_Modeフラグは考慮されないことに注意してください。
(600) While in this state, a VRRP router MUST do the following:
（600）この状態では、VRRPルーターは次のことを実行する必要があります。
(605) - If the protected IPvX address is an IPv4 address, then:
（605）-保護されたIPvXアドレスがIPv4アドレスの場合：
(610) + MUST respond to ARP requests for the IPv4 address(es) associated with the virtual router.
（610）+仮想ルーターに関連付けられたIPv4アドレスのARP要求に応答する必要があります。
(615) - else // ipv6
(620) + MUST be a member of the Solicited-Node multicast address for the IPv6 address(es) associated with the virtual router.
（620）+仮想ルーターに関連付けられているIPv6アドレスの要請ノードマルチキャストアドレスのメンバーである必要があります。
(625) + MUST respond to ND Neighbor Solicitation message for the IPv6 address(es) associated with the virtual router.
（625）+仮想ルーターに関連付けられたIPv6アドレスのND近隣要請メッセージに応答する必要があります。
(630) ++ MUST send ND Router Advertisements for the virtual router.
（630）++は、仮想ルーターのNDルーターアドバタイズを送信する必要があります。
(635) ++ If Accept_Mode is False: MUST NOT drop IPv6 Neighbor Solicitations and Neighbor Advertisements.
（635）++ Accept_ModeがFalseの場合：IPv6近隣要請および近隣アドバタイズメントをドロップしてはならない（MUST NOT）。
(640) +-endif // ipv4?
(645) - MUST forward packets with a destination link-layer MAC address equal to the virtual router MAC address.
（645）-仮想ルーターのMACアドレスと等しい宛先リンク層MACアドレスでパケットを転送する必要があります。
(650) - MUST accept packets addressed to the IPvX address(es) associated with the virtual router if it is the IPvX address owner or if Accept_Mode is True. Otherwise, MUST NOT accept these packets.
（650）-IPvXアドレスの所有者である場合、またはAccept_ModeがTrueの場合、仮想ルーターに関連付けられたIPvXアドレスにアドレス指定されたパケットを受け入れる必要があります。それ以外の場合は、これらのパケットを受け入れてはなりません。
(655) - If a Shutdown event is received, then:
（655）-シャットダウンイベントを受信した場合：
(660) + Cancel the Adver_Timer
（660）+ Adver_Timerをキャンセルする
(665) + Send an ADVERTISEMENT with Priority = 0
（665）+優先度= 0の広告を送信
(670) + Transition to the {Initialize} state
(675) -endif // shutdown recv
(680) - If the Adver_Timer fires, then:
（680）-Adver_Timerが発生した場合：
(685) + Send an ADVERTISEMENT
（685）+広告を送信
(690) + Reset the Adver_Timer to Advertisement_Interval
（690）+ Adver_TimerをAdvertisement_Intervalにリセット
(695) -endif // advertisement timer fired
(700) - If an ADVERTISEMENT is received, then:
（700）-ADVERTISEMENTが受信されると、次のようになります。
(705) -+ If the Priority in the ADVERTISEMENT is zero, then:
（705）-+ ADVERTISEMENTの優先度がゼロの場合、次のようになります。
(710) -* Send an ADVERTISEMENT
（710）-*広告を送信する
(715) -* Reset the Adver_Timer to Advertisement_Interval
（715）-* Adver_TimerをAdvertisement_Intervalにリセットします
(720) -+ else // priority was non-zero
(725) -* If the Priority in the ADVERTISEMENT is greater than the local Priority,
（725）-* ADVERTISEMENTの優先度がローカルの優先度より大きい場合、
(730) -* or
（730）-*または
(735) -* If the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IPvX Address of the sender is greater than the local primary IPvX Address, then:
（735）-* ADVERTISEMENTの優先度がローカルの優先度と等しく、送信者のプライマリIPvXアドレスがローカルのプライマリIPvXアドレスより大きい場合、次のようになります。
(740) -@ Cancel Adver_Timer
（740）-@ Adver_Timerをキャンセル
(745) -@ Set Master_Adver_Interval to Adver Interval contained in the ADVERTISEMENT
（745）-@ Master_Adver_IntervalをADVERTISEMENTに含まれるAdver Intervalに設定します
(750) -@ Recompute the Skew_Time
（750）-@ Skew_Timeを再計算します
(755) @ Recompute the Master_Down_Interval
（755）@ Master_Down_Intervalを再計算する
(760) @ Set Master_Down_Timer to Master_Down_Interval
（760）@ Master_Down_TimerをMaster_Down_Intervalに設定
(765) @ Transition to the {Backup} state
(770) * else // new Master logic
(775) @ Discard ADVERTISEMENT
（775）@広告を破棄
(780) *endif // new Master detected
(785) +endif // was priority zero?
(790) -endif // advert recv
(795) endwhile // in Master
（795）endwhile //マスター
The following functions are performed when a VRRP packet is received:
VRRPパケットを受信すると、次の機能が実行されます。
- If the received packet is an IPv4 packet, then:
- 受信したパケットがIPv4パケットの場合：
+ MUST verify that the IPv4 TTL is 255.
+ IPv4 TTLが255であることを確認する必要があります。
- else // ipv6 recv
- else // ipv6 recv
+ MUST verify that the IPv6 Hop Limit is 255.
+ IPv6ホップ制限が255であることを確認する必要があります。
-endif
-endif
- MUST verify that the VRRP version is 3.
- VRRPバージョンが3であることを確認する必要があります。
- MUST verify that the received packet contains the complete VRRP packet (including fixed fields, and IPvX address).
- 受信したパケットに完全なVRRPパケット（固定フィールドとIPvXアドレスを含む）が含まれていることを確認する必要があります。
- MUST verify the VRRP checksum.
- VRRPチェックサムを確認する必要があります。
- MUST verify that the VRID is configured on the receiving interface and the local router is not the IPvX address owner (Priority = 255 (decimal)).
- VRIDが受信インターフェイスで構成され、ローカルルーターがIPvXアドレスの所有者ではないことを確認する必要があります（優先度= 255（10進数））。
If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event, and MAY indicate via network management that an error occurred.
上記のチェックのいずれかが失敗した場合、受信者はパケットを破棄し、イベントを記録する必要があり（SHOULD）、ネットワーク管理を介してエラーが発生したことを示すことができます（MAY）。
- MAY verify that "Count IPvX Addrs" and the list of IPvX address(es) match the IPvX Address(es) configured for the VRID.
- 「カウントIPv4アドレス」およびIPアドレスのリスト）がVRIDに構成されたIPvXアドレスと一致することを確認できます（MAY）。
If the above check fails, the receiver SHOULD log the event and MAY indicate via network management that a misconfiguration was detected.
上記のチェックが失敗した場合、受信者はイベントをログに記録する必要があり（SHOULD）、ネットワーク管理を介して、設定ミスが検出されたことを示すことができます（MAY）。
The following operations MUST be performed when transmitting a VRRP packet:
VRRPパケットを送信するときは、次の操作を実行する必要があります。
- Fill in the VRRP packet fields with the appropriate virtual router configuration state
- VRRPパケットフィールドに適切な仮想ルーター構成状態を入力します
- Compute the VRRP checksum
- VRRPチェックサムを計算する
- If the protected address is an IPv4 address, then:
- 保護されたアドレスがIPv4アドレスの場合：
+ Set the source MAC address to virtual router MAC Address
+ 送信元MACアドレスを仮想ルーターMACアドレスに設定します
+ Set the source IPv4 address to interface primary IPv4 address
+ ソースIPv4アドレスをプライマリIPv4アドレスのインターフェースに設定する
- else // ipv6
- それ以外// ipv6
+ Set the source MAC address to virtual router MAC Address
+ 送信元MACアドレスを仮想ルーターMACアドレスに設定します
+ Set the source IPv6 address to interface link-local IPv6 address
+ ソースIPv6アドレスをインターフェイスのリンクローカルIPv6アドレスに設定します
-endif
-endif
- Set the IPvX protocol to VRRP
- IPvXプロトコルをVRRPに設定する
- Send the VRRP packet to the VRRP IPvX multicast group
- VRRPパケットをVRRP IPvXマルチキャストグループに送信する
Note: VRRP packets are transmitted with the virtual router MAC address as the source MAC address to ensure that learning bridges correctly determine the LAN segment the virtual router is attached to.
注：VRRPパケットは、送信元MACアドレスとして仮想ルーターのMACアドレスを使用して送信され、学習ブリッジが仮想ルーターが接続されているLANセグメントを正しく判別できるようにします。
The virtual router MAC address associated with a virtual router is an IEEE 802 MAC Address in the following format:
仮想ルーターに関連付けられた仮想ルーターのMACアドレスは、次の形式のIEEE 802 MACアドレスです。
IPv4 case: 00-00-5E-00-01-{VRID} (in hex, in Internet-standard bit-order)
IPv4ケース：00-00-5E-00-01- {VRID}（16進数、インターネット標準ビット順）
The first three octets are derived from the IANA's Organizational Unique Identifier (OUI). The next two octets (00-01) indicate the address block assigned to the VRRP for IPv4 protocol. {VRID} is the VRRP Virtual Router Identifier. This mapping provides for up to 255 IPv4 VRRP routers on a network.
最初の3つのオクテットは、IANAの組織固有識別子（OUI）から派生しています。次の2つのオクテット（00-01）は、IPv4プロトコルのVRRPに割り当てられたアドレスブロックを示します。 {VRID}はVRRP仮想ルーター識別子です。このマッピングは、ネットワーク上で最大255のIPv4 VRRPルーターを提供します。
IPv6 case: 00-00-5E-00-02-{VRID} (in hex, in Internet-standard bit-order)
IPv6ケース：00-00-5E-00-02- {VRID}（16進数、インターネット標準ビット順）
The first three octets are derived from the IANA's OUI. The next two octets (00-02) indicate the address block assigned to the VRRP for IPv6 protocol. {VRID} is the VRRP Virtual Router Identifier. This mapping provides for up to 255 IPv6 VRRP routers on a network.
最初の3つのオクテットは、IANAのOUIから派生しています。次の2つのオクテット（00-02）は、IPv6プロトコルのVRRPに割り当てられたアドレスブロックを示します。 {VRID}はVRRP仮想ルーター識別子です。このマッピングは、ネットワーク上で最大255のIPv6 VRRPルーターを提供します。
IPv6 routers running VRRP MUST create their Interface Identifiers in the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet Networks" [RFC2464]). They MUST NOT use the virtual router MAC address to create the Modified Extended Unique Identifier (EUI)-64 identifiers.
VRRPを実行するIPv6ルーターは、通常の方法でインターフェイス識別子を作成する必要があります（たとえば、「イーサネットネットワークを介したIPv6パケットの送信」[RFC2464]）。仮想ルーターのMACアドレスを使用して、Modified Extended Unique Identifier（EUI）-64識別子を作成してはなりません（MUST NOT）。
This VRRP specification describes how to advertise and resolve the VRRP router's IPv6 link-local address and other associated IPv6 addresses into the virtual router MAC address.
このVRRP仕様では、VRRPルーターのIPv6リンクローカルアドレスと他の関連するIPv6アドレスをアドバタイズして解決し、仮想ルーターのMACアドレスに変換する方法について説明しています。
ICMP redirects may be used normally when VRRP is running between a group of routers. This allows VRRP to be used in environments where the topology is not symmetric.
ルーターのグループ間でVRRPが実行されている場合、ICMPリダイレクトは通常使用できます。これにより、トポロジが対称でない環境でVRRPを使用できます。
The IPv4 source address of an ICMP redirect should be the address that the end-host used when making its next-hop routing decision. If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address. One method to deduce the virtual router used is to examine the destination MAC address in the packet that triggered the redirect.
ICMPリダイレクトのIPv4送信元アドレスは、エンドホストがネクストホップルーティングを決定するときに使用したアドレスにする必要があります。 VRRPルーターが、所有していないアドレスを含む仮想ルーターのマスターとして機能している場合、リダイレクトの送信元アドレスを選択するときに、パケットが送信された仮想ルーターを特定する必要があります。使用される仮想ルーターを推定する1つの方法は、リダイレクトをトリガーしたパケットの宛先MACアドレスを調べることです。
It may be useful to disable redirects for specific cases where VRRP is being used to load-share traffic between a number of routers in a symmetric topology.
対称トポロジの多数のルーター間でトラフィックをロードシェアするためにVRRPが使用されている特定のケースでは、リダイレクトを無効にすることが役立つ場合があります。
When a host sends an ARP request for one of the virtual router IPv4 addresses, the Virtual Router Master MUST respond to the ARP request with an ARP response that indicates the virtual MAC address for the virtual router. Note that the source address of the Ethernet frame of this ARP response is the physical MAC address of the physical router. The Virtual Router Master MUST NOT respond with its physical MAC address in the ARP response. This allows the client to always use the same MAC address regardless of the current Master router.
ホストが仮想ルーターのIPv4アドレスの1つに対するARP要求を送信すると、仮想ルーターマスターは、仮想ルーターの仮想MACアドレスを示すARP応答でARP要求に応答する必要があります。このARP応答のイーサネットフレームの送信元アドレスは、物理ルーターの物理MACアドレスであることに注意してください。仮想ルーターマスターは、ARP応答で物理MACアドレスを使用して応答してはなりません（MUST NOT）。これにより、現在のマスタールーターに関係なく、クライアントは常に同じMACアドレスを使用できます。
When a VRRP router restarts or boots, it SHOULD NOT send any ARP messages using its physical MAC address for the IPv4 address it owns; it should only send ARP messages that include virtual MAC addresses.
VRRPルーターは、再起動または起動するときに、所有するIPv4アドレスの物理MACアドレスを使用してARPメッセージを送信してはなりません（SHOULD NOT）。仮想MACアドレスを含むARPメッセージのみを送信する必要があります。
This may entail the following:
これには、次のことが含まれます。
o When configuring an interface, Virtual Router Master routers should broadcast a gratuitous ARP request containing the virtual router MAC address for each IPv4 address on that interface.
o インターフェイスを構成するとき、仮想ルーターマスタールーターは、そのインターフェイスの各IPv4アドレスの仮想ルーターMACアドレスを含むGratuitous ARP要求をブロードキャストする必要があります。
o At system boot, when initializing interfaces for VRRP operation, delay gratuitous ARP requests and ARP responses until both the IPv4 address and the virtual router MAC address are configured.
o システムブート時に、VRRP動作用にインターフェイスを初期化するときは、IPv4アドレスと仮想ルーターMACアドレスの両方が構成されるまで、Gratuitous ARP要求とARP応答を遅延させます。
o When, for example, ssh access to a particular VRRP router is required, an IP address known to belong to that router must be used.
o たとえば、特定のVRRPルーターへのsshアクセスが必要な場合、そのルーターに属することがわかっているIPアドレスを使用する必要があります。
If Proxy ARP is to be used on a VRRP router, then the VRRP router must advertise the virtual router MAC address in the Proxy ARP message. Doing otherwise could cause hosts to learn the real MAC address of the VRRP router.
VRRPルーターでプロキシARPを使用する場合、VRRPルーターはプロキシARPメッセージで仮想ルーターのMACアドレスを通知する必要があります。そうしないと、ホストがVRRPルーターの実際のMACアドレスを学習する可能性があります。
ICMPv6 redirects may be used normally when VRRP is running between a group of routers [RFC4443]. This allows VRRP to be used in environments where the topology is not symmetric (e.g., the VRRP routers do not connect to the same destinations).
ICMPv6リダイレクトは、VRRPがルーターのグループ間で実行されている場合に通常使用できます[RFC4443]。これにより、トポロジが対称ではない環境（VRRPルーターが同じ宛先に接続しないなど）でVRRPを使用できます。
The IPv6 source address of an ICMPv6 redirect should be the address that the end-host used when making its next-hop routing decision. If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address. A method to deduce the virtual router used is to examine the destination MAC address in the packet that triggered the redirect.
ICMPv6リダイレクトのIPv6送信元アドレスは、エンドホストがネクストホップルーティングを決定するときに使用したアドレスである必要があります。 VRRPルーターが、所有していないアドレスを含む仮想ルーターのマスターとして機能している場合、リダイレクトの送信元アドレスを選択するときに、パケットが送信された仮想ルーターを特定する必要があります。使用されている仮想ルーターを推定する方法は、リダイレクトをトリガーしたパケットの宛先MACアドレスを調べることです。
When a host sends an ND Neighbor Solicitation message for the virtual router IPv6 address, the Virtual Router Master MUST respond to the ND Neighbor Solicitation message with the virtual MAC address for the virtual router. The Virtual Router Master MUST NOT respond with its physical MAC address. This allows the client to always use the same MAC address regardless of the current Master router.
ホストが仮想ルーターのIPv6アドレスのND近隣要請メッセージを送信する場合、仮想ルーターマスターは、仮想ルーターの仮想MACアドレスでND近隣要請メッセージに応答する必要があります。仮想ルーターマスターは、物理MACアドレスで応答してはなりません（MUST NOT）。これにより、現在のマスタールーターに関係なく、クライアントは常に同じMACアドレスを使用できます。
When a Virtual Router Master sends an ND Neighbor Solicitation message for a host's IPv6 address, the Virtual Router Master MUST include the virtual MAC address for the virtual router if it sends a source link-layer address option in the neighbor solicitation message. It MUST NOT use its physical MAC address in the source link-layer address option.
仮想ルーターマスターがホストのIPv6アドレスのND近隣要請メッセージを送信するとき、仮想ルーターマスターは、近隣要請メッセージでソースリンク層アドレスオプションを送信する場合、仮想ルーターの仮想MACアドレスを含める必要があります。ソースリンク層アドレスオプションで物理MACアドレスを使用してはなりません（MUST NOT）。
When a VRRP router restarts or boots, it SHOULD NOT send any ND messages with its physical MAC address for the IPv6 address it owns; it should only send ND messages that include virtual MAC addresses.
VRRPルーターは、再起動または起動するときに、所有するIPv6アドレスの物理MACアドレスを含むNDメッセージを送信してはなりません（SHOULD NOT）。仮想MACアドレスを含むNDメッセージのみを送信する必要があります。
This may entail the following:
これには、次のことが含まれます。
o When configuring an interface, Virtual Router Master routers should send an unsolicited ND Neighbor Advertisement message containing the virtual router MAC address for the IPv6 address on that interface.
o インターフェイスを構成するとき、仮想ルーターマスタールーターは、そのインターフェイスのIPv6アドレスの仮想ルーターMACアドレスを含む非請求NDネイバーアドバタイズメッセージを送信する必要があります。
o At system boot, when initializing interfaces for VRRP operation, all ND Router and Neighbor Advertisements and Solicitation messages must be delayed until both the IPv6 address and the virtual router MAC address are configured.
o At system boot, when initializing interfaces for VRRP operation, all ND Router and Neighbor Advertisements and Solicitation messages must be delayed until both the IPv6 address and the virtual router MAC address are configured.
Note that on a restarting Master router where the VRRP protected address is the interface address, (that is, priority 255) duplicate address detection (DAD) may fail, as the Backup router may answer that it owns the address. One solution is to not run DAD in this case.
VRRP保護アドレスがインターフェースアドレス（つまり、優先度255）である再起動マスタールーターでは、バックアップルーターがアドレスを所有していると応答する可能性があるため、重複アドレス検出（DAD）が失敗する場合があります。この場合、DADを実行しないという解決策があります。
When a Backup VRRP router has become Master for a virtual router, it is responsible for sending Router Advertisements for the virtual router as specified in Section 6.4.3. The Backup routers must be configured to send the same Router Advertisement options as the address owner.
バックアップVRRPルーターが仮想ルーターのマスターになると、セクション6.4.3で指定されているように、仮想ルーターのルーターアドバタイズを送信します。バックアップルーターは、アドレス所有者と同じルーターアドバタイズオプションを送信するように構成する必要があります。
Router Advertisement options that advertise special services (e.g., Home Agent Information Option) that are present in the address owner should not be sent by the address owner unless the Backup routers are prepared to assume these services in full and have a complete and synchronized database for this service.
バックアップルーターがこれらのサービスを完全に想定し、完全な同期データベースを備えている準備ができていない限り、アドレスオーナーに存在する特別なサービス（ホームエージェント情報オプションなど）をアドバタイズするルーターアドバタイズメントオプションは、アドレスオーナーによって送信されるべきではありません。このサービス。
If it is not the address owner, a VRRP router SHOULD NOT forward packets addressed to the IPvX address for which it becomes Master. Forwarding these packets would result in unnecessary traffic. Also, in the case of LANs that receive packets they transmit (e.g., Token Ring), this can result in a forwarding loop that is only terminated when the IPvX TTL expires.
それがアドレス所有者でない場合、VRRPルーターは、それがマスターになるIPvXアドレスにアドレス指定されたパケットを転送してはなりません（SHOULD NOT）。これらのパケットを転送すると、不要なトラフィックが発生します。また、それらが送信するパケットを受信するLAN（トークンリングなど）の場合、IPvX TTLの期限が切れたときにのみ終了する転送ループが発生する可能性があります。
One such mechanism for VRRP routers is to add/delete a reject host route for each adopted IPvX address when transitioning to/from MASTER state.
VRRPルーターのそのようなメカニズムの1つは、MASTER状態への移行またはMASTER状態からの移行時に、採用されたIPvXアドレスごとに拒否ホストルートを追加/削除することです。
A priority value of 255 designates a particular router as the "IPvX address owner". Care must be taken not to configure more than one router on the link in this way for a single VRID.
プライオリティ値255は、特定のルーターを「IPvXアドレス所有者」として指定します。このようにして、1つのVRIDに対してリンク上に複数のルーターを構成しないように注意する必要があります。
Routers with priority 255 will, as soon as they start up, preempt all lower-priority routers. No more than one router on the link is to be configured with priority 255, especially if preemption is set. If no router has this priority, and preemption is disabled, then no preemption will occur.
優先度が255のルーターは、起動するとすぐに、優先度の低いルーターをすべて横取りします。特にプリエンプションが設定されている場合は、リンク上のルーターに優先度255を設定しないでください。この優先順位を持つルーターがなく、プリエンプションが無効になっている場合、プリエンプションは発生しません。
When there are multiple Backup routers, their priority values should be uniformly distributed. For example, if one Backup router has the default priority of 100 and another Backup Router is added, a priority of 50 would be a better choice for it than 99 or 100, in order to facilitate faster convergence.
複数のBackupルーターがある場合、それらの優先度の値は均一に分散する必要があります。たとえば、1つのバックアップルーターのデフォルトの優先度が100で、別のバックアップルーターが追加された場合、より高速な収束を容易にするために、優先度は99または100よりも50の方が適切です。
1. VRRPv2 and VRRPv3 interoperation is optional.
1. VRRPv2とVRRPv3の相互運用はオプションです。
2. Mixing VRRPv2 and VRRPv3 should only be done when transitioning from VRRPv2 to VRRPv3. Mixing the two versions should not be considered a permanent solution.
2. VRRPv2とVRRPv3の混合は、VRRPv2からVRRPv3への移行時にのみ実行する必要があります。 2つのバージョンを混在させることは、永続的な解決策とは見なされません。
As mentioned above, this support is intended for upgrade scenarios and is NOT recommended for permanent deployments.
上記のように、このサポートはアップグレードシナリオを対象としており、永続的な展開には推奨されません。
An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements.
実装は、VRRPv2とVRRPv3の両方のアドバタイズをリッスンして送信するように指示する構成フラグを実装してもよい（MAY）。
When a virtual router is configured this way and is the Master, it MUST send both types at the configured rate, even if sub-second.
仮想ルーターがこのように構成され、マスターである場合、1秒未満であっても、構成されたレートで両方のタイプを送信する必要があります。
When a virtual router is configured this way and is the Backup, it should time out based on the rate advertised by the Master; in the case of a VRRPv2 Master, this means it must translate the timeout value it receives (in seconds) into centiseconds. Also, a Backup should ignore VRRPv2 advertisements from the current Master if it is also receiving VRRPv3 packets from it. It MAY report when a VRRPv3 Master is *not* sending VRRPv2 packets: that suggests they don't agree on whether they're supporting VRRPv2 routers.
仮想ルーターがこのように構成され、バックアップである場合、マスターによってアドバタイズされたレートに基づいてタイムアウトする必要があります。 VRRPv2マスターの場合、これは、受信するタイムアウト値（秒単位）をセンチ秒に変換する必要があることを意味します。また、バックアップは、現在のマスターからVRRPv3パケットも受信している場合、現在のマスターからのVRRPv2アドバタイズを無視する必要があります。 VRRPv3マスターがVRRPv2パケットを送信していない場合は、レポートする場合があります。つまり、VRRPv2ルーターをサポートしているかどうかに同意していないことを示しています。
See also Section 5.2.7, "Maximum Advertisement Interval (Max Adver Int)".
5.2.7項「最大の広告間隔（Max Adver Int）」も参照してください。
The VRRPv2 Master router interacting with a sub-second VRRPv3 Backup router is the most important example of this.
1秒未満のVRRPv3バックアップルーターと対話するVRRPv2マスタールーターは、この最も重要な例です。
A VRRPv2 implementation should not be given a higher priority than a VRRPv2/VRRPv3 implementation it is interacting with if the VRRPv2/ VRRPv3 rate is sub-second.
VRRPv2 / VRRPv3レートが1秒未満の場合、VRRPv2の実装には、VRRPv2 / VRRPv3が対話しているVRRPv2 / VRRPv3の実装よりも高い優先順位を与えないでください。
It seems possible that a VRRPv3 Master router sending at centisecond rates could potentially overwhelm a VRRPv2 Backup router with potentially unclear results.
センチ秒の速度で送信しているVRRPv3マスタールーターがVRRPv2バックアップルーターを圧倒し、結果が不明確になる可能性があります。
In this upgrade case, a deployment should initially run the VRRPv3 Master routers with lower frequencies (e.g., 100 centiseconds) until the VRRPv2 routers are upgraded. Then, once the deployment has convinced itself that VRRPv3 is working properly, the VRRPv2 support may be unconfigured and then the desired sub-second rates configured.
このアップグレードの場合、展開では最初にVRRPv2ルーターがアップグレードされるまで、低い周波数（100センチ秒など）でVRRPv3マスタールーターを実行する必要があります。次に、VRRPv3が適切に機能していることをデプロイメントが確信したら、VRRPv2サポートを構成解除してから、必要な1秒未満のレートを構成できます。
VRRP for IPvX does not currently include any type of authentication. Earlier versions of the VRRP (for IPv4) specification included several types of authentication ranging from none to strong. Operational experience and further analysis determined that these did not provide sufficient security to overcome the vulnerability of misconfigured secrets, causing multiple Masters to be elected. Due to the nature of the VRRP protocol, even if VRRP messages are cryptographically protected, it does not prevent hostile nodes from behaving as if they are a VRRP Master, creating multiple Masters. Authentication of VRRP messages could have prevented a hostile node from causing all properly functioning routers from going into Backup state. However, having multiple Masters can cause as much disruption as no routers, which authentication cannot prevent. Also, even if a hostile node could not disrupt VRRP, it can disrupt ARP and create the same effect as having all routers go into Backup.
IPvXのVRRPには現在、どのタイプの認証も含まれていません。以前のバージョンのVRRP（IPv4用）仕様には、なしから強力までのさまざまなタイプの認証が含まれていました。運用経験と詳細な分析により、これらの設定では、誤って構成されたシークレットの脆弱性を克服するのに十分なセキュリティが提供されず、複数のマスターが選出されることが判明しました。 VRRPプロトコルの性質上、VRRPメッセージが暗号で保護されている場合でも、敵意のあるノードがVRRPマスターであるかのように動作して複数のマスターを作成することは妨げられません。 VRRPメッセージの認証により、悪意のあるノードが適切に機能しているすべてのルーターをバックアップ状態にすることができなかった可能性があります。ただし、複数のマスターがあると、ルーターがない場合と同じくらいの混乱が生じる可能性があり、認証ではこれを防止できません。また、悪意のあるノードがVRRPを妨害できなくても、ARPを妨害し、すべてのルーターをバックアップに入れるのと同じ効果を生み出す可能性があります。
Some L2 switches provide the capability to filter out, for example, ARP and/or ND messages from end-hosts on a switch-port basis. This mechanism could also filter VRRP messages from switch ports associated with end-hosts and can be considered for deployments with untrusted hosts.
一部のL2スイッチは、たとえば、スイッチポートベースでエンドホストからのARPまたはNDメッセージ、あるいはその両方をフィルターで除外する機能を提供します。このメカニズムは、エンドホストに関連付けられたスイッチポートからのVRRPメッセージをフィルタリングすることもでき、信頼されていないホストを使用した展開と見なすことができます。
It should be noted that these attacks are not worse and are a subset
of the attacks that any node attached to a LAN can do independently
of VRRP. The kind of attacks a malicious node on a LAN can do
include promiscuously receiving packets for any router's MAC address;
sending packets with the router's MAC address as the source MAC
address in the L2 header to tell the L2 switches to send packets
addressed to the router to the malicious node instead of the router;
send redirects to tell the hosts to send their traffic somewhere
else; send unsolicited ND replies; answer ND requests; etc. All of
this can be done independently of implementing VRRP. VRRP does not
add to these vulnerabilities.
Independent of any authentication type, VRRP includes a mechanism (setting TTL = 255, checking on receipt) that protects against VRRP packets being injected from another remote network. This limits most vulnerabilities to local attacks.
どの認証タイプからも独立して、VRRPには、VRRPパケットが別のリモートネットワークから挿入されるのを防ぐメカニズム（TTL = 255の設定、受信時のチェック）が含まれています。これにより、ほとんどの脆弱性がローカル攻撃に限定されます。
VRRP does not provide any confidentiality. Confidentiality is not necessary for the correct operation of VRRP, and there is no information in the VRRP messages that must be kept secret from other nodes on the LAN.
VRRPは機密性を提供しません。 VRRPが正しく動作するために機密性は必要ありません。また、VRRPメッセージには、LAN上の他のノードから秘密にしておく必要のある情報はありません。
In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND) is deployed, VRRP is compatible with the "trust anchor" and "trust anchor or cga" modes of SEND [RFC3971]. The SEND configuration needs to give the Master and Backup routers the same prefix delegation in the certificates so that Master and Backup routers advertise the same set of subnet prefixes. However, the Master and Backup routers should have their own key pairs to avoid private key sharing.
IPv6動作のコンテキストでは、SEcure近隣探索（SEND）が展開されている場合、VRRPはSENDの「トラストアンカー」および「トラストアンカーまたはcga」モードと互換性があります[RFC3971]。 SEND構成では、マスタールーターとバックアップルーターが同じサブネットプレフィックスのセットをアドバタイズするように、マスタールーターとバックアップルーターに証明書の同じプレフィックス委任を与える必要があります。ただし、マスタールータとバックアップルータには、秘密キーの共有を回避するための独自のキーペアが必要です。
The editor would like to thank V. Ullanatt for his review of an early version. This document consists of very little new material (there is some new text in Appendix A) and was created by merging and "xml-izing" [VRRP-IPv6] and [RFC3768], and then adding in the changes discussed recently on the Virtual Router Redundancy Protocol working group's mailing list. R. Hinden is the author and J. Cruz the editor of the former. The contributors for the latter appear below.
The editor would like to thank V. Ullanatt for his review of an early version. This document consists of very little new material (there is some new text in Appendix A) and was created by merging and "xml-izing" [VRRP-IPv6] and [RFC3768], and then adding in the changes discussed recently on the Virtual Router Redundancy Protocol working group's mailing list. R. Hinden is the author and J. Cruz the editor of the former. The contributors for the latter appear below.
The IPv6 text in this specification is based on [RFC2338]. The authors of RFC2338 are S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, and A. Lindem.
この仕様のIPv6テキストは[RFC2338]に基づいています。 RFC2338の作成者は、S。ナイト、D。ウィーバー、D。ウィップル、R。ヒンデン、D。ミツェル、P。ハント、P。ヒギンソン、M。シャンド、およびA.リンデムです。
The author of [VRRP-IPv6] would also like to thank Erik Nordmark, Thomas Narten, Steve Deering, Radia Perlman, Danny Mitzel, Mukesh Gupta, Don Provan, Mark Hollinger, John Cruz, and Melissa Johnson for their helpful suggestions.
[VRRP-IPv6]の作成者も、Erik Nordmark、Thomas Narten、Steve Deering、Radia Perlman、Danny Mitzel、Mukesh Gupta、Don Provan、Mark Hollinger、John Cruz、Melissa Johnsonの各氏の有益な提案に感謝します。
The IPv4 text in this specification is based on [RFC3768]. The authors of that specification would like to thank Glen Zorn, Michael Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun, Radia Perlman, Russ Housley, Harald Alvestrand, Steve Bellovin, Ned Freed, Ted Hardie, Russ Housley, Bert Wijnen, Bill Fenner, and Alex Zinin for their comments and suggestions.
この仕様のIPv4テキストは[RFC3768]に基づいています。この仕様の作成者は、グレンゾーン、マイケルレーン、クラークブレーマー、ハルピーターソン、トニーリー、バーバラデニー、ジョエルハルパーン、スティーブベロビン、トーマスナルテン、ロブモンゴメリー、ロブコルトゥーン、ラディアパールマン、ラスハウズリー、ハラルドアルベストランドに感謝します、Steve Bellovin、Ned Freed、Ted Hardie、Russ Housley、Bert Wijnen、Bill Fenner、Alex Zininのコメントと提案。
IANA has assigned an IPv6 link-local scope multicast address for VRRP for IPv6. The IPv6 multicast address is as follows:
IANA has assigned an IPv6 link-local scope multicast address for VRRP for IPv6. The IPv6 multicast address is as follows:
FF02:0:0:0:0:0:0:12
The values assigned address should be entered into Section 5.1.2.2.
アドレスが割り当てられた値は、セクション5.1.2.2に入力する必要があります。
The IANA has reserved a block of IANA Ethernet unicast addresses for VRRP for IPv6 in the range
IANAは、範囲内のIPv6のVRRP用にIANAイーサネットユニキャストアドレスのブロックを予約しました
00-00-5E-00-02-00 to 00-00-5E-00-02-FF (in hex)
00-00-5E-00-02-00〜00-00-5E-00-02-FF（16進数）
Similar assignments are documented at:
同様の割り当ては次の場所に記載されています。
http://www.iana.org
[ISO.10038.1993] International Organization for Standardization, "Information technology - Telecommunications and information exchange between systems - Local area networks - Media access control (MAC) bridges", ISO Standard 10038, 1993.
[ISO.10038.1993]国際標準化機構、「情報技術-システム間の通信および情報交換-ローカルエリアネットワーク-メディアアクセスコントロール（MAC）ブリッジ」、ISO標準10038、1993。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
[RFC3768] Hinden、R。、「Virtual Router Redundancy Protocol（VRRP）」、RFC 3768、2004年4月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[VRRP-IPv6] Hinden, R. and J. Cruz, "Virtual Router Redundancy Protocol for IPv6", Work in Progress, March 2007.
[VRRP-IPv6] Hinden、R。およびJ. Cruz、「IPv6の仮想ルーター冗長プロトコル」、作業中、2007年3月。
[IPSTB] Higginson, P. and M. Shand, "Development of Router Clusters to Provide Fast Failover in IP Networks", Digital Technical Journal, Volume 9 Number 3, Winter 1997.
[IPSTB] Higginson、P。およびM. Shand、「IPネットワークで高速フェイルオーバーを提供するルータークラスタの開発」、Digital Technical Journal、Volume 9 Number 3、Winter 1997。
[IPX] Novell Incorporated, "IPX Router Specification Version 1.10", October 1992.
[IPX] Novell Incorporated, "IPX Router Specification Version 1.10", October 1992.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC1071] Braden、R.、Borman、D.、Partridge、C。、およびW. Plummer、「Computing the Internet checksum」、RFC 1071、1988年9月。
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256] Deering、S。、編、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[RFC1469] Pusateri, T., "IP Multicast over Token-Ring Local Area Networks", RFC 1469, June 1993.
[RFC1469] Pusateri、T。、「トークンリングローカルエリアネットワーク上のIPマルチキャスト」、RFC 1469、1993年6月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby Router Protocol (HSRP)", RFC 2281, March 1998.
[RFC2281] Li、T.、Cole、B.、Morton、P。、およびD. Li、「Cisco Hot Standby Router Protocol（HSRP）」、RFC 2281、1998年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M., and A. Lindem, "Virtual Router Redundancy Protocol", RFC 2338, April 1998.
[RFC2338]ナイト、S。、ウィーバー、D。、ホイップル、D。、ヒンデン、R。、ミッツェル、D。、ハント、P。、ヒギンソン、P。、シャンド、M。、およびA.リンデム、「仮想ルーター冗長プロトコル」、RFC 2338、1998年4月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、1998年12月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、March 2005。
[TKARCH] IBM Incorporated, "IBM Token-Ring Network, Architecture Specification, Publication SC30-3374-02, Third Edition", September 1989.
[TKARCH] IBM Incorporated、「IBM Token-Ring Network、Architecture Specification、Publication SC30-3374-02、Third Edition」、1989年9月。
Appendix A. Operation over FDDI, Token Ring, and ATM LANE
付録A.FDDI、トークンリング、およびATM LANEを介した操作
FDDI interfaces remove from the FDDI ring frames that have a source MAC address matching the device's hardware address. Under some conditions, such as router isolations, ring failures, protocol transitions, etc., VRRP may cause there to be more than one Master router. If a Master router installs the virtual router MAC address as the hardware address on a FDDI device, then other Masters' ADVERTISEMENTS will be removed from the ring during the Master convergence, and convergence will fail.
FDDIインターフェイスは、デバイスのハードウェアアドレスと一致する送信元MACアドレスを持つFDDIリングフレームから削除します。ルーターの分離、リングの障害、プロトコルの移行などの一部の状況下では、VRRPによって複数のマスタールーターが存在する場合があります。マスタールーターが仮想ルーターのMACアドレスをFDDIデバイスのハードウェアアドレスとしてインストールすると、他のマスターのADVERTISEMENTSがマスターコンバージェンス中にリングから削除され、コンバージェンスは失敗します。
To avoid this, an implementation SHOULD configure the virtual router MAC address by adding a unicast MAC filter in the FDDI device, rather than changing its hardware MAC address. This will prevent a Master router from removing any ADVERTISEMENTS it did not originate.
これを回避するには、ハードウェアMACアドレスを変更するのではなく、FDDIデバイスにユニキャストMACフィルターを追加して、仮想ルーターMACアドレスを構成する必要があります（SHOULD）。これにより、マスタールーターが元の広告を削除しなくなります。
Token Ring has several characteristics that make running VRRP difficult. These include the following:
トークンリングには、VRRPの実行を困難にするいくつかの特性があります。これらには以下が含まれます。
o In order to switch to a new Master located on a different bridge Token-Ring segment from the previous Master when using source-route bridges, a mechanism is required to update cached source-route information.
o ソースルートブリッジを使用しているときに、以前のマスターとは異なるブリッジトークンリングセグメントにある新しいマスターに切り替えるには、キャッシュされたソースルート情報を更新するメカニズムが必要です。
o No general multicast mechanism is supported across old and new Token-Ring adapter implementations. While many newer Token-Ring adapters support group addresses, Token-Ring functional-address support is the only generally available multicast mechanism. Due to the limited number of Token-Ring functional addresses, these may collide with other usage of the same Token-Ring functional addresses.
o 新旧のトークンリングアダプタの実装では、一般的なマルチキャストメカニズムはサポートされていません。新しいトークンリングアダプターの多くはグループアドレスをサポートしていますが、トークンリングの機能アドレスのサポートは、一般的に利用可能な唯一のマルチキャストメカニズムです。トークンリング機能アドレスの数が限られているため、これらは同じトークンリング機能アドレスの他の使用法と衝突する可能性があります。
Due to these difficulties, the preferred mode of operation over Token Ring will be to use a Token-Ring functional address for the VRID virtual MAC address. Token-Ring functional addresses have the two high-order bits in the first MAC address octet set to B'1'. They range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format). However, unlike multicast addresses, there is only one unique functional address per bit position. The functional addresses 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved by the Token-Ring Architecture [TKARCH] for user-defined applications. However, since there are only 12 user-defined Token-Ring functional addresses, there may be other non-IPvX protocols using the same functional address. Since the Novell IPX [IPX] protocol uses the
これらの問題のため、トークンリングよりも優先される操作モードは、VRID仮想MACアドレスにトークンリング機能アドレスを使用することです。トークンリング機能アドレスは、最初のMACアドレスオクテットの2つの上位ビットがB'1 'に設定されています。それらの範囲は03-00-00-00-00-80から03-00-02-00-00-00（標準形式）です。ただし、マルチキャストアドレスとは異なり、ビット位置ごとに一意の機能アドレスは1つしかありません。機能アドレス03-00-00-10-00-00から03-00-02-00-00-00は、ユーザー定義アプリケーション用のトークンリングアーキテクチャ[TKARCH]によって予約されています。ただし、ユーザー定義のトークンリング機能アドレスは12個しかないため、同じ機能アドレスを使用する他の非IPvXプロトコルが存在する可能性があります。 Novell IPX [IPX]プロトコルは
03-00-00-10-00-00 functional address, operation of VRRP over Token Ring will avoid use of this functional address. In general, Token-Ring VRRP users will be responsible for resolution of other user-defined Token-Ring functional address conflicts.
03-00-00-10-00-00機能アドレス、トークンリング上のVRRPの操作は、この機能アドレスの使用を回避します。一般に、トークンリングVRRPユーザーは、他のユーザー定義のトークンリング機能アドレスの競合の解決を担当します。
VRIDs are mapped directly to Token-Ring functional addresses. In order to decrease the likelihood of functional-address conflicts, allocation will begin with the largest functional address. Most non-IPvX protocols use the first or first couple user-defined functional addresses, and it is expected that VRRP users will choose VRIDs sequentially, starting with 1.
VRIDは、トークンリング機能アドレスに直接マップされます。機能アドレスの競合の可能性を減らすために、割り当ては最大の機能アドレスから開始されます。ほとんどの非IPvXプロトコルは、最初または最初のカップルのユーザー定義の機能アドレスを使用します。VRRPユーザーは、VRIDを1から順に選択することが予想されます。
VRID Token-Ring Functional Address
---- -----------------------------
1 03-00-02-00-00-00
2 03-00-04-00-00-00
3 03-00-08-00-00-00
4 03-00-10-00-00-00
5 03-00-20-00-00-00
6 03-00-40-00-00-00
7 03-00-80-00-00-00
8 03-00-00-01-00-00
9 03-00-00-02-00-00
10 03-00-00-04-00-00
11 03-00-00-08-00-00
Or, more succinctly, octets 3 and 4 of the functional address are equal to (0x4000 >> (VRID - 1)) in non-canonical format.
または、より簡潔に言えば、機能アドレスのオクテット3と4は、非正規形式では（0x4000 >>（VRID-1））と等しくなります。
Since a functional address cannot be used as a MAC-level source address, the real MAC address is used as the MAC source address in VRRP advertisements. This is not a problem for bridges, since packets addressed to functional addresses will be sent on the spanning-tree explorer path [ISO.10038.1993].
機能アドレスはMACレベルの送信元アドレスとして使用できないため、実際のMACアドレスはVRRPアドバタイズメントのMAC送信元アドレスとして使用されます。機能アドレスにアドレス指定されたパケットはスパニングツリーエクスプローラパス[ISO.10038.1993]で送信されるため、これはブリッジの問題ではありません。
The functional-address mode of operation MUST be implemented by routers supporting VRRP on Token Ring.
機能アドレスモードの動作は、トークンリングでVRRPをサポートするルーターによって実装する必要があります。
Additionally, routers MAY support the unicast mode of operation to take advantage of newer Token-Ring adapter implementations that support non-promiscuous reception for multiple unicast MAC addresses and to avoid both the multicast traffic and usage conflicts associated with the use of Token-Ring functional addresses. Unicast mode uses the same mapping of VRIDs to virtual MAC addresses as Ethernet. However, one important difference exists. ND request/reply packets contain the virtual MAC address as the source MAC address. The reason for this is that some Token-Ring driver implementations keep a cache of MAC address/source-routing information independent of the ND cache.
さらに、ルーターは、ユニキャストモードの操作をサポートして、複数のユニキャストMACアドレスの無差別受信をサポートする新しいトークンリングアダプターの実装を利用し、トークンリング機能の使用に関連するマルチキャストトラフィックと使用法の競合を回避することができます（MAY）。アドレス。ユニキャストモードでは、イーサネットと同じVRIDの仮想MACアドレスへのマッピングを使用します。ただし、重要な違いが1つあります。 ND要求/応答パケットには、送信元MACアドレスとして仮想MACアドレスが含まれています。これは、トークンリングドライバーの実装によっては、NDキャッシュとは無関係にMACアドレス/ソースルーティング情報のキャッシュが保持されるためです。
Hence, these implementations have to receive a packet with the virtual MAC address as the source address in order to transmit to that MAC address in a source-route-bridged network.
したがって、これらの実装は、ソースルートブリッジネットワークでMACアドレスに送信するために、仮想MACアドレスをソースアドレスとして持つパケットを受信する必要があります。
Unicast mode on Token Ring has one limitation that should be considered. If there are VRID routers on different source-route-bridge segments, and there are host implementations that keep their source-route information in the ND cache and do not listen to gratuitous NDs, these hosts will not update their ND source-route information correctly when a switchover occurs. The only possible solution is to put all routers with the same VRID on the same source-route-bridge segment and use techniques to prevent that bridge segment from being a single point of failure. These techniques are beyond the scope of this document.
トークンリングのユニキャストモードには、考慮すべき制限が1つあります。異なるソースルートブリッジセグメントにVRIDルーターがあり、そのソースルート情報をNDキャッシュに保持し、無償のNDをリッスンしないホスト実装がある場合、これらのホストはNDソースルート情報を正しく更新しませんスイッチオーバーが発生したとき。唯一可能な解決策は、同じVRIDを持つすべてのルーターを同じソースルートブリッジセグメントに配置し、そのブリッジセグメントが単一障害点になるのを防ぐための手法を使用することです。これらの手法は、このドキュメントの範囲を超えています。
For both the multicast and unicast mode of operation, VRRP advertisements sent to 224.0.0.18 should be encapsulated as described in [RFC1469].
マルチキャストモードとユニキャストモードのどちらの動作でも、224.0.0.18に送信されるVRRPアドバタイズメントは、[RFC1469]で説明されているようにカプセル化する必要があります。
Operation of VRRP over ATM LANE on routers with ATM LANE interfaces and/or routers behind proxy LAN Emulation Clients (LECs) are beyond the scope of this document.
ATM LANEインターフェイスを備えたルーターやプロキシLANエミュレーションクライアント（LEC）の背後にあるルーターでのVRRP over ATM LANEの操作は、このドキュメントの範囲外です。
Author's Address
著者のアドレス
Stephen Nadas (editor) Ericsson 900 Chelmsford St., T3 4th Floor Lowell, MA 01851 USA
Stephen Nadas（編集者）Ericsson 900 Chelmsford St.、T3 4th Floor Lowell、MA 01851 USA
Phone: +1 978 275 7448
EMail: stephen.nadas@ericsson.com