RFC2338 日本語訳
2338 Virtual Router Redundancy Protocol. S. Knight, D. Weaver, D.Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A.Lindem. April 1998. (Format: TXT=59871 bytes) (Obsoleted by RFC3768) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Knight
Request for Comments: 2338 D. Weaver
Category: Standards Track Ascend Communications, Inc.
D. Whipple
Microsoft, Inc.
R. Hinden
D. Mitzel
P. Hunt
Nokia
P. Higginson
M. Shand
Digital Equipment Corp.
A. Lindem
IBM Corporation
April 1998
コメントを求めるワーキンググループS.ナイト要求をネットワークでつないでください: 2338年のD.ウィーバーカテゴリ: 規格道はInc.D.ホイップルマイクロソフトInc.R.Hinden D.Mitzel P.がノキアP.ヒギンソンM.シャンドディジタル・イクイップメント社A.Lindem IBM社の1998年4月に捜すコミュニケーションを昇ります。
Virtual Router Redundancy Protocol
仮想のルータ冗長プロトコル
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This memo defines the Virtual Router Redundancy Protocol (VRRP). 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 IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to 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.
このメモはVirtual Router Redundancyプロトコル(VRRP)を定義します。 VRRPはダイナミックにLANのVRRPルータの1つに仮想のルータへの責任を割り当てる選挙プロトコルを指定します。 仮想のルータに関連しているIPアドレス(es)を制御するVRRPルータは、Masterと呼ばれて、これらのIPアドレスに送られたパケットを進めます。 Masterが入手できなくなるなら、選挙プロセスはダイナミックなフェイルオーバーを推進責任に提供します。 これは終わりホストでIPがデフォルトとして使用されるためにLANで扱う仮想のルータのいずれにも最初に、ホップルータを許容します。 VRRPを使用することで得られる利点はすべての終わりホストの上でダイナミックルーティングかルータ発見プロトコルの構成を必要とすることのない、より高い有用性デフォルト経路です。
Knight, et. al. Standards Track [Page 1] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[1ページ]。
Table of Contents
目次
1. Introduction...............................................2
2. Required Features..........................................5
3. VRRP Overview..............................................6
4. Sample Configurations......................................8
5. Protocol...................................................9
5.1 VRRP Packet Format....................................10
5.2 IP Field Descriptions.................................10
5.3 VRRP Field Descriptions...............................11
6. Protocol State Machine....................................13
6.1 Parameters............................................13
6.2 Timers................................................15
6.3 State Transition Diagram..............................15
6.4 State Descriptions....................................15
7. Sending and Receiving VRRP Packets........................18
7.1 Receiving VRRP Packets................................18
7.2 Transmitting Packets..................................19
7.3 Virtual MAC Address...................................19
8. Operational Issues........................................20
8.1 ICMP Redirects........................................20
8.2 Host ARP Requests.....................................20
8.3 Proxy ARP.............................................20
9. Operation over FDDI and Token Ring........................21
9.1 Operation over FDDI...................................21
9.2 Operation over Token Ring.............................21
10. Security Considerations...................................23
10.1 No Authentication....................................23
10.2 Simple Text Password.................................23
10.3 IP Authentication Header.............................24
11. Acknowledgments...........................................24
12. References................................................24
13. Authors' Addresses........................................25
14. Full Copyright Statement..................................27
1. 序論…2 2. 特徴を必要とします…5 3. VRRP概要…6 4. 構成を抽出してください…8 5. 議定書を作ってください…9 5.1 VRRPパケット・フォーマット…10 5.2 IPフィールド記述…10 5.3 VRRPは記述をさばきます…11 6. 州のマシンについて議定書の中で述べてください…13 6.1のパラメタ…13 6.2個のタイマ…15 6.3 変遷ダイヤグラムを述べてください…15 6.4 記述を述べてください…15 7. 送受信VRRPパケット…18 7.1 VRRPパケットを受けます…18 7.2 パケットを伝えます…19 7.3 仮想のマックーアドレス…19 8. 操作上の問題…8.1ICMPが向け直す20…20 8.2 ARP要求を主催してください…20 8.3 プロキシARP…20 9. FDDIの上の操作とトークンは鳴ります…21 FDDIの上の9.1操作…21 トークンリングの上の9.2操作…21 10. セキュリティ問題…23 10.1 認証がありません…23 10.2の簡単なテキストパスワード…23 10.3IP認証ヘッダー…24 11. 承認…24 12. 参照…24 13. 作者のアドレス…25 14. 完全な著作権宣言文…27
1. Introduction
1. 序論
There are a number of methods that an end-host can use to determine its first hop router towards a particular IP destination. These include running (or snooping) a dynamic routing protocol such as Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running an ICMP router discovery client [DISC] or using a statically configured default route.
終わりホストが特定のIPの目的地に向かって最初のホップルータを決定するのに使用できる多くのメソッドがあります。 これらは、ルーティング情報プロトコルなどのダイナミックルーティングプロトコル[RIP]かOSPFバージョン2[OSPF]を実行するのを(または、詮索します)含んでいます、ICMPルータ発見クライアント[DISC]を車で送るか、または静的に構成されたデフォルトルートを使用して。
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
いくつかのためのプロトコル実装の実行不可能な管理オーバーヘッドを含んでいて、様々な意味で処理しているオーバーヘッド、安全保障問題、または不足がプラットホーム隣人かルータ発見であったかもしれないならすべての終わりホストにダイナミックルーティングプロトコルを実行します。
Knight, et. al. Standards Track [Page 2] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[2ページ]。
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, which 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 IP implementation. This mode of operation is likely to persist as dynamic host configuration protocols [DHCP] are deployed, which typically provide configuration for an end-host IP 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.
静的に構成されたデフォルトルートの使用はかなりポピュラーです。 それは、終わりホストで構成と処理オーバヘッドを最小にして、実際にはあらゆるIP実装によってサポートされます。 動的ホスト構成プロトコル[DHCP](終わりホストIPアドレスとデフォルトゲートウェイに構成を通常提供する)が配布されるとき、この運転モードは固執しそうです。 しかしながら、これは1ポイントの失敗を作成します。 デフォルトルータの損失は大惨事をもたらします、どんな利用可能であるかもしれない代替パスも検出できないすべての終わりホストを隔離して。
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 IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility should the Master become unavailable. Any of the virtual router's IP 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.
Virtual Router Redundancyプロトコル(VRRP)は、静的なデフォルト発送された環境で固有の失敗の単一のポイントを排除するように設計されています。 VRRPはダイナミックにLANのVRRPルータの1つに仮想のルータへの責任を割り当てる選挙プロトコルを指定します。 仮想のルータに関連しているIPアドレス(es)を制御するVRRPルータは、Masterと呼ばれて、これらのIPアドレスに送られたパケットを進めます。 Masterが入手できなくなるなら、選挙プロセスはダイナミックなフェイルオーバーを推進責任に提供します。 そして、デフォルトが最初に終わりホストでルータを飛び越すとき、LANに関する仮想のルータのIPアドレスのいずれも使用できます。 VRRPを使用することで得られる利点はすべての終わりホストの上でダイナミックルーティングかルータ発見プロトコルの構成を必要とすることのない、より高い有用性デフォルト経路です。
VRRP provides a function similar to a Cisco Systems, Inc. proprietary protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a Digital Equipment Corporation, Inc. proprietary protocol named IP Standby Protocol [IPSTB].
VRRPはIP StandbyプロトコルというDEC Inc.固有のプロトコル[IPSTB]とHot Standby Routerプロトコル(HSRP)というシスコシステムズInc.固有のプロトコル[HSRP]と、そして、同様の機能を提供します。
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 [RFC 2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The IESG/IETF take no position regarding the validity or scope of any intellectual property right or other rights that might be claimed to pertain to the implementation or use of the technology, or the extent to which any license under such rights might or might not be available. See the IETF IPR web page at http://www.ietf.org/ipr.html for additional information.
IESG/IETFは正当性、実装に関係すると主張されるどんな知的所有権や他の権利の範囲か技術の使用、またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 http://www.ietf.org/ipr.html で追加情報に関してIETF IPRウェブページを見てください。
Knight, et. al. Standards Track [Page 3] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[3ページ]。
1.1 Scope
1.1 範囲
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の特徴、デザイン目標、および動作理論について説明します。 メッセージ・フォーマット、プロトコル処理規則、およびそれが提示されるのを独身のVirtual Router Masterへの集合に保証する州のマシン。 最終的に、操作上の問題はMACアドレス・マッピングに関係しました、ARP要求の取り扱い、ICMPの再直接のメッセージの世代、そして、安全保障問題が扱われます。
This protocol is intended for use with IPv4 routers only. A separate specification will be produced if it is decided that similar functionality is desirable in an IPv6 environment.
このプロトコルはIPv4ルータだけがある使用のために意図します。 同様の機能性がIPv6環境で望ましいと決められると、別々の仕様は作り出されるでしょう。
1.2 Definitions
1.2 定義
VRRP Router A router running the Virtual Router Redundancy
Protocol. It may participate in one or more
virtual routers.
Virtual Router Redundancyプロトコルを実行するVRRP Router Aルータ。 それは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
a set of associated IP address(es) across a
common LAN. A VRRP Router may backup one or
more virtual routers.
仮想のRouter An抽象的なオブジェクトはホストのためのデフォルトルータとして共有されたLANに機能するVRRPによって管理されました。 それは一般的なLANの向こう側に関連IPアドレス(es)のVirtual Router Identifierとセットから成ります。 VRRP Routerは1つ以上の仮想のルータのバックアップをとるかもしれません。
IP Address Owner The VRRP router that has the virtual router's
IP address(es) as real interface address(es).
This is the router that, when up, will respond
to packets addressed to one of these IP
addresses for ICMP pings, TCP connections,
etc.
IP Address Owner、本当であるとしての仮想のルータのIPアドレス(es)がアドレス(es)を連結するVRRPルータ。 これは上がるときICMPピング、TCP接続などのためのこれらのIPアドレスの1つに扱われたパケットに応じるルータです。
Primary IP Address An IP address selected from the set of real
interface addresses. One possible selection
algorithm is to always select the first
address. VRRP advertisements are always sent
using the primary IP address as the source of
the IP packet.
プライマリIP Address An IPアドレスは本当のインターフェース・アドレスのセットから選び抜きました。 1つの可能な選択アルゴリズムはいつも最初のアドレスを選択することです。 VRRP広告にIPパケットの源としてプライマリIPアドレスをいつも使用させます。
Virtual Router Master The VRRP router that is assuming the
responsibility of forwarding packets sent to
the IP address(es) associated with the virtual
router, and answering ARP requests for these
IP addresses. Note that if the IP address
owner is available, then it will always become
the Master.
仮想のRouter Master、パケットを進める責任を負っているVRRPルータは仮想のルータと、ARPに答えると関連しているIPアドレス(es)にこれらのIPアドレスを求める要求を送りました。 IPアドレス所有者が手があくならそれがいつもMasterになることに注意してください。
Knight, et. al. Standards Track [Page 4] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[4ページ]。
Virtual Router Backup The set of VRRP routers available to assume
forwarding responsibility for a virtual router
should the current Master fail.
仮想のRouter Backupは仮想のルータへの推進責任はMasterが失敗する電流がそうするべきであると仮定するために利用可能なVRRPルータのセットです。
2.0 Required Features
2.0 必要な特徴
This section outlines the set of features that were considered mandatory and that guided the design of VRRP.
このセクションは義務的であると考えられて、VRRPのデザインを誘導した特徴のセットについて概説します。
2.1 IP Address Backup
2.1 IPアドレスバックアップ
Backup of IP addresses is the primary function of the Virtual Router Redundancy Protocol. While providing election of a Virtual Router Master and the additional functionality described below, the protocol should strive to:
IPアドレスのバックアップはVirtual Router Redundancyプロトコルのプライマリ機能です。 Virtual Router Masterの選挙と以下で説明された追加機能性を提供している間、プロトコルは、以下のことように努力するべきです。
- Minimize the duration of black holes.
- Minimize the steady state bandwidth overhead and processing
complexity.
- Function over a wide variety of multiaccess LAN technologies
capable of supporting IP traffic.
- Provide for election of multiple virtual routers on a network for
load balancing
- Support of multiple logical IP subnets on a single LAN segment.
- ブラックホールの持続時間を最小にしてください。 - 定常状態帯域幅オーバーヘッドと処理の複雑さを最小にしてください。 - IPトラフィックをサポートすることができるさまざまな多重処理LAN技術の上の機能。 - ロードバランシングのためにネットワークにおける複数の仮想のルータの選挙に備えてください--単一のLANセグメントにおける複数の論理的なIPサブネットのサポート。
2.2 Preferred Path Indication
2.2 都合のよい経路指示
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.
余分なルータのセットの中のMaster選挙の単純モデルはMasterとしてどんなルータにも一点に集まった後に、等しい好みとクレームの勝利で各ルータを扱うことになっています。 しかしながら、余分なルータのセットの中に異なった優先(または、好みの範囲)がある多くの環境がありそうです。 例えば、この好みはアクセスリンク費用、速度、ルータ性能、信頼性、または他の方針問題に基づくかもしれません。 プロトコルは直感的な方法におけるこの相対パス好み、および現在利用可能な最も優先ののルータへの保証Master集合の式を許容するべきです。
2.3 Minimization of Unnecessary Service Disruptions
2.3 不要なサービスの崩壊の最小化
Once Master election has been performed then 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.
一度、Master選挙は実行されたことがあって、次に、MasterとBackupルータの間のどんな不要な変遷も使用中の状態で分裂をもたらすことができます。 プロトコルは、Master選挙の後にMasterが、適切に機能し続けている限り、状態遷移が全く等しいか下側の好みのどんなBackupルータによっても引き起こされないのを確実にするべきです。
Knight, et. al. Standards Track [Page 5] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[5ページ]。
Some environments may find it beneficial to avoid the state transition triggered when a router becomes available that is more preferential than the current Master. It may be useful to support an override of the immediate convergence to the preferred path.
いくつかの環境によって、ルータが利用可能になるとき引き起こされた現在のMasterより優先のである状態遷移を避けるのが有益であることがわかるかもしれません。 即座の集合のオーバーライドを都合のよい経路にサポートするのは役に立つかもしれません。
2.4 Extensible Security
2.4 広げることができるセキュリティ
The virtual router functionality is applicable to a wide range of internetworking environments that may employ different security policies. The protocol should require minimal configuration and overhead in the insecure operation, provide for strong authentication when increased security is required, and allow integration of new security mechanisms without breaking backwards compatible operation.
仮想のルータの機能性は異なった安全保障政策を使うかもしれないさまざまなインターネットワーキング環境に適切です。 後方にコンパチブル操作を壊さないで、プロトコルは、不安定な操作で最小量の構成とオーバーヘッドを必要として、増強されたセキュリティが必要であるときに、強い認証に備えて、新しいセキュリティー対策の統合を許容するべきです。
2.5 Efficient Operation over Extended LANs
2.5 拡張LANの上の効率的な操作
Sending IP packets on a multiaccess LAN requires mapping from an IP 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 as the source in a packet sent by the Master to trigger station learning; 2) trigger a message immediately after transitioning to Master to update the station learning; and 3) trigger periodic messages from the Master to maintain the station learning cache.
IPパケットを多重処理LANに送るのは、IPアドレスからMACアドレスまで写像するのを必要とします。 拡張LANにおける仮想のルータMACアドレスのラーニングブリッジを使う使用は仮想のルータに送られたパケットの帯域幅オーバーヘッドに重要な影響を与えることができます。 ステーションの位置は決して学習されません、仮想のルータに送られたすべてのパケットの氾濫をもたらして仮想のルータMACアドレスがソースアドレスとしてリンク・レベルフレームで決して使用されないなら。 この環境で能率を上げるために、プロトコルはそうするべきです: 1) パケットのソースがステーション学習の引き金となるようにMasterで発信したので、仮想のルータMACを使用してください。 2) ステーション学習をアップデートするためにMasterに移行する直後メッセージの引き金となってください。 そして、3は、)ステーション学習キャッシュを維持するためにMasterから周期的なメッセージの引き金となります。
3.0 VRRP Overview
3.0 VRRP概要
VRRP specifies an election protocol to provide the virtual router function described earlier. All protocol messaging is performed using IP multicast datagrams, thus the protocol can operate over a variety of multiaccess LAN technologies supporting IP multicast. Each 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は、より早く説明された仮想のルータ機能を提供するために選挙プロトコルを指定します。 すべてのプロトコルメッセージングがIPマルチキャストデータグラムを使用することで実行されます、その結果、プロトコルは、IPマルチキャストをサポートしながら、さまざまな多重処理LAN技術の上で作動できます。 それぞれのVRRPの仮想のルータで、ただ一つのよく知られるMACアドレスをそれに割り当てます。 このドキュメントは、現在、IEEE802の48ビットのMACアドレスを使用することでマッピングをネットワークに詳しく述べるだけです。 すべての周期的なVRRPメッセージのソースが拡張LANにおけるブリッジ学習を可能にするためにMasterルータで発信したので、仮想のルータMACアドレスは使用されています。
A virtual router is defined by its virtual router identifier (VRID) and a set of IP addresses. A VRRP router may associate a virtual router with its real addresses on an interface, and may also be configured with additional virtual router mappings and priority for virtual routers it is willing to backup. The mapping between VRID and addresses must be coordinated among all VRRP routers on a LAN.
仮想のルータは仮想のルータ識別子(VRID)とIPアドレスのセットによって定義されます。 VRRPルータは、インタフェースに関する本当のアドレスに仮想のルータを関連づけて、また、それがバックアップをとっても構わないと思っている仮想のルータのために追加仮想のルータマッピングと優先権によって構成されるかもしれません。 LANに関するすべてのVRRPルータの中でVRIDとアドレスの間のマッピングを調整しなければなりません。
Knight, et. al. Standards Track [Page 6] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[6ページ]。
However, there is no restriction against reusing a VRID with a different address mapping on different LANs. The scope of each virtual router is restricted to a single LAN.
しかしながら、異なったLANに関する異なったアドレス・マッピングでVRIDを再利用することに反対して制限は全くいません。 それぞれの仮想のルータの範囲は単一のLANに制限されます。
To minimize network traffic, only the Master for each virtual router sends periodic VRRP Advertisement messages. A Backup router will not attempt to pre-empt 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 pre- emption 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.
ネットワークトラフィックを最小にするために、それぞれの仮想のルータのためのMasterだけが周期的なVRRP Advertisementメッセージを送ります。 それにより高い優先度がないと、Backupルータは、Masterを先取りするのを試みないでしょう。 より都合のよい経路が利用可能にならない場合、これはサービスの崩壊を排除します。 また、行政上すべてのプレemption試みを禁止するのも可能です。 唯一の例外はVRRPルータがいつもそれが所有しているアドレスに関連しているどんな仮想のルータのMasterにもなるということです。 Masterが入手できなくなると、最優先Backupは最小量の停電による仮想のルータ責任の制御変遷を提供する少し遅れの後のMasterへの変遷がそうするでしょう。
VRRP defines three types of authentication providing simple deployment in insecure environments, added protection against misconfiguration, and strong sender authentication in security conscious environments. Analysis of the protection provided and vulnerability of each mechanism is deferred to Section 10.0 Security Considerations. In addition new authentication types and data can be defined in the future without affecting the format of the fixed portion of the protocol packet, thus preserving backward compatible operation.
VRRPは不安定な環境における簡単な展開、misconfigurationに対する加えられた保護、および強い送付者認証に安全に意識している環境を提供する3つのタイプの認証を定義します。 保護の分析は供給されました、そして、それぞれのメカニズムの脆弱性はセクション10.0 Security Considerationsに延期されます。 さらに、プロトコルパケットの固定部分の形式に影響しないで、将来新しい認証タイプとデータを定義できます、その結果、後方のコンパチブル操作を保存します。
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プロトコルデザインは、停電を最小にするためにBackupからMasterまでの急速な変化を提供して、典型的な操作上のシナリオのための制御Master変遷を保証している間、プロトコルの複雑さを減少させる最適化を取り入れます。 最小量のランタイムがある選挙プロトコルの最適化結果は要件、最小量の活動的なプロトコル州、単独のメッセージタイプ、および送付者を述べます。 典型的な操作上のシナリオは、各ルータの中の2つの余分なルータ、そして/または、異なった経路好みになるように定義されます。 これらの仮定が違反されるときの副作用(すなわち、等しい好みがあるすべて、2つ以上の冗長パス)はMaster選挙の間の簡潔な期間写しパケットを進めるかもしれないということです。 しかしながら、典型的なシナリオ仮定は展開のかなりの大部分をカバーしそうであって、Masterルータの損失は珍しく、Master選挙集合における予想された持続時間はかなり小さいです(<<1 2番目)。 したがって、VRRP最適化は簡潔なネットワーク退行の意味をなさない確率を被っている間、プロトコルデザインにおける重要な簡素化を表します。
Knight, et. al. Standards Track [Page 7] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[7ページ]。
4. Sample Configurations
4. サンプル構成
4.1 Sample Configuration 1
4.1 サンプル構成1
The following figure shows a simple network with two VRRP routers implementing one virtual router. Note that this example is provided to help understand the protocol, but is not expected to occur in actual practice.
以下の図は2つのVRRPルータが1つの仮想のルータを実装している簡単なネットワークを示しています。 この例をプロトコルを理解しているのを助けるために提供しますが、実際行なわれているところでは起こらないと予想することに注意してください。
+-----+ +-----+
| MR1 | | BR1 |
| | | |
| | | |
VRID=1 +-----+ +-----+
IP A ---------->* *<--------- IP B
| |
| |
| |
------------------+------------+-----+--------+--------+--------+--
^ ^ ^ ^
| | | |
(IP A) (IP A) (IP A) (IP A)
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
+-----+ +-----+ | MR1| | BR1| | | | | | | | | VRID=1+-----+ +-----+ IP A---------->* *<、-、-、-、-、-、-、-、-- IP B| | | | | | ------------------+------------+-----+--------+--------+--------+-- ^ ^ ^ ^ | | | | (IP a) (IP a) (IP a) (IP a) | | | | +--+--+ +--+--+ +--+--+ +--+--+ | H1| | H2| | H3| | H4| +-----+ +-----+ +--+--+ +--+--+
Legend:
---+---+---+-- = Ethernet, Token Ring, or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IP Address
(IP) = default router for hosts
伝説: ---+---+---+--= マスターホストコンピュータイーサネット、Token Ring、またはFDDI H=MR=Router BRはホストのためにデフォルトバックアップRouter*=IP Address(IP)=ルータと等しいです。
The above configuration shows a very simple VRRP scenario. In this configuration, the end-hosts install a default route to the IP address of virtual router #1 (IP A) and both routers run VRRP. The router on the left becomes the Master for virtual router #1 (VRID=1) and the router on the right is the Backup for virtual router #1. If the router on the left should fail, the other router will take over virtual router #1 and its IP addresses, and provide uninterrupted service for the hosts.
上の構成は非常に簡単なVRRPシナリオを示しています。 この構成では、終わりホストは仮想のルータ#1(IP A)のIPアドレスにデフォルトルートをインストールします、そして、両方のルータはVRRPを実行します。 左のルータは仮想のルータ#1(VRID=1)のためのMasterになります、そして、右のルータは仮想のルータ#1のためのBackupです。 左のルータが失敗すると、もう片方のルータは、仮想のルータ#1とそのIPアドレスを引き継いで、ホストのためのとぎれないサービスを提供するでしょう。
Note that in this example, IP B is not backed up by the router on the left. IP B is only used by the router on the right as its interface address. In order to backup IP B, a second virtual router would have to be configured. This is shown in the next section.
この例では、IP Bが左のルータによって支援されないことに注意してください。 IP Bはインターフェース・アドレスとして右のルータによって使用されるだけです。 IP Bのバックアップをとるために、2番目の仮想のルータは構成されなければならないでしょう。 これは次のセクションで示されます。
Knight, et. al. Standards Track [Page 8] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[8ページ]。
4.2 Sample Configuration 2
4.2 サンプル構成2
The following figure shows a configuration with two virtual routers with the hosts spitting their traffic between them. This example is expected to be very common in actual practice.
以下の図はホストが彼らの間の彼らのトラフィックに痰唾を吐いている2つの仮想のルータで構成を示しています。 この例が実際行なわれているところでは非常に一般的であると予想されます。
+-----+ +-----+
| MR1 | | MR2 |
| & | | & |
| BR2 | | BR1 |
VRID=1 +-----+ +-----+ VRID=2
IP A ---------->* *<---------- IP B
| |
| |
| |
------------------+------------+-----+--------+--------+--------+--
^ ^ ^ ^
| | | |
(IP A) (IP A) (IP B) (IP B)
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
+-----+ +-----+ | MR1| | MR2| | & | | & | | BR2| | BR1| VRID=1+-----+ +-----+ VRID=2IP A---------->* *<、-、-、-、-、-、-、-、-、-- IP B| | | | | | ------------------+------------+-----+--------+--------+--------+-- ^ ^ ^ ^ | | | | (IP a) (IP a) (IP B) (IP B) | | | | +--+--+ +--+--+ +--+--+ +--+--+ | H1| | H2| | H3| | H4| +-----+ +-----+ +--+--+ +--+--+
Legend:
---+---+---+-- = Ethernet, Token Ring, or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IP Address
(IP) = default router for hosts
伝説: ---+---+---+--= マスターホストコンピュータイーサネット、Token Ring、またはFDDI H=MR=Router BRはホストのためにデフォルトバックアップRouter*=IP Address(IP)=ルータと等しいです。
In the above configuration, half of the hosts install a default route to virtual router #1's IP address (IP A), and the other half of the hosts install a default route to virtual router #2's IP address (IP B). This has the effect of load balancing the outgoing traffic, while also providing full redundancy.
上の構成では、半分のホストは仮想のルータ#1IPアドレス(IP A)にデフォルトルートをインストールします、そして、ホストのもう片方の半分は仮想のルータ#2IPアドレス(IP B)にデフォルトルートをインストールします。 これには、また、完全な冗長を提供している間、外向的が取引するロードバランシングの効果があります。
5.0 Protocol
5.0 プロトコル
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 Virtual Router ID.
VRRPパケットの目的は優先権とVirtual Router IDに関連しているMasterルータの状態をすべてのVRRPルータに伝えることです。
VRRP packets are sent encapsulated in IP packets. They are sent to the IPv4 multicast address assigned to VRRP.
パケットが送られるVRRPはIPパケットで要約しました。 VRRPに割り当てられたIPv4マルチキャストアドレスにそれらを送ります。
Knight, et. al. Standards Track [Page 9] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[9ページ]。
5.1 VRRP Packet Format
5.1 VRRPパケット・フォーマット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority | Count IP Addrs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Adver Int | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| タイプ| 仮想のRtr ID| 優先権| IP Addrsを数えてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authはタイプします。| Adver Int| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPアドレス(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPアドレス(n)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証データ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証データ(2)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2 IP Field Descriptions
5.2 IPフィールド記述
5.2.1 Source Address
5.2.1 ソースアドレス
The primary IP address of the interface the packet is being sent from.
パケットが送られるインタフェースのプライマリIPアドレス。
5.2.2 Destination Address
5.2.2 送付先アドレス
The IP multicast address as assigned by the IANA for VRRP is:
VRRPのためにIANAによって割り当てられるIPマルチキャストアドレスは以下の通りです。
224.0.0.18
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にかかわらずこの送付先アドレスがあるデータグラムを進めてはいけません。
5.2.3 TTL
5.2.3 TTL
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 MUST、255に設定されてください。 255と等しくないTTLと共にパケットを受けるVRRPルータはパケットを捨てなければなりません。
Knight, et. al. Standards Track [Page 10] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[10ページ]。
5.2.4 Protocol
5.2.4 プロトコル
The IP protocol number assigned by the IANA for VRRP is 112 (decimal).
VRRPのためにIANAによって割り当てられたIPプロトコル番号は112(10進)です。
5.3 VRRP Field Descriptions
5.3 VRRPフィールド記述
5.3.1 Version
5.3.1 バージョン
The version field specifies the VRRP protocol version of this packet. This document defines version 2.
バージョン分野はこのパケットのVRRPプロトコルバージョンを指定します。 このドキュメントはバージョン2を定義します。
5.3.2 Type
5.3.2 タイプ
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.
未知のタイプがあるパケットを捨てなければなりません。
5.3.3 Virtual Rtr ID (VRID)
5.3.3 仮想のRtr ID(VRID)
The Virtual Router Identifier (VRID) field identifies the virtual router this packet is reporting status for.
Virtual Router Identifier(VRID)分野はこのパケットが状態を報告している仮想のルータを特定します。
5.3.4 Priority
5.3.4 優先権
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 IP address(es) associated with the virtual router MUST be 255 (decimal).
仮想のルータに関連しているIPアドレス(es)を所有している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).
仮想のルータへの支援が1-254(10進)に優先順位の値を使用しなければならないVRRPルータ。 仮想のルータを支援する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 timeout.
優先順位の値ゼロ(0)には、現在のMasterが、VRRPに参加するのを止めたのを示す特別な意味があります。 これは、すばやく現在のMasterをタイムアウトに待つ必要はなくてMasterに移行するのに引き金のBackupルータに使用されます。
5.3.5 Count IP Addrs
5.3.5 IP Addrsを数えてください。
The number of IP addresses contained in this VRRP advertisement.
このVRRP広告に含まれたIPアドレスの数。
Knight, et. al. Standards Track [Page 11] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[11ページ]。
5.3.6 Authentication Type
5.3.6 認証タイプ
The authentication type field identifies the authentication method being utilized. Authentication type is unique on a per interface basis. The authentication type field is an 8 bit unsigned integer. A packet with unknown authentication type or that does not match the locally configured authentication method MUST be discarded.
利用されていて、認証タイプ分野は認証方法を特定します。 認証タイプはインタフェース基礎あたりのaでユニークです。 認証タイプ分野は8の噛み付いている符号のない整数です。 未知の認証タイプかそれがあるパケットは捨てられて、メソッドがそうしなければならない局所的に構成された認証に合っていません。
The authentication methods currently defined are:
現在定義されている認証方法は以下の通りです。
0 - No Authentication
1 - Simple Text Password
2 - IP Authentication Header
0--いいえ認証1--簡単なテキストパスワード2--IP認証ヘッダー
5.3.6.1 No Authentication
5.3.6.1 認証がありません。
The use of this authentication type means that VRRP protocol exchanges are not authenticated. The contents of the Authentication Data field should be set to zero on transmission and ignored on reception.
この認証タイプの使用は、VRRPプロトコル交換が認証されないことを意味します。 Authentication Data分野のコンテンツは、トランスミッションのときにゼロに設定されて、レセプションで無視されるべきです。
5.3.6.2 Simple Text Password
5.3.6.2 簡単なテキストパスワード
The use of this authentication type means that VRRP protocol exchanges are authenticated by a clear text password. The contents of the Authentication Data field should be set to the locally configured password on transmission. There is no default password. The receiver MUST check that the Authentication Data in the packet matches its configured authentication string. Packets that do not match MUST be discarded.
この認証タイプの使用は、VRRPプロトコル交換がクリアテキストパスワードによって認証されることを意味します。 Authentication Data分野のコンテンツはトランスミッションに関する局所的に構成されたパスワードに設定されるべきです。 デフォルトパスワードが全くありません。 受信機は、パケットのAuthentication Dataが構成された認証ストリングに合っているのをチェックしなければなりません。 合っていないパケットを捨てなければなりません。
Note that there are security implications to using Simple Text password authentication, and one should see the Security Consideration section of this document.
Simple Textパスワード認証を使用することへのセキュリティ含意があることに注意してください。そうすれば、このドキュメントのSecurity Consideration部を見るべきです。
5.3.6.3 IP Authentication Header
5.3.6.3 IP認証ヘッダー
The use of this authentication type means the VRRP protocol exchanges are authenticated using the mechanisms defined by the IP Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP and AH" [HMAC]. Keys may be either configured manually or via a key distribution protocol.
この認証タイプの使用が、VRRPプロトコル交換がIP Authentication Header[AUTH]使用で定義されたメカニズムを使用することで認証されることを意味する、「」 ああ、超能力の中のHMAC-MD5-96と[HMAC]の使用。 キーが手動で構成されるか、主要な分配プロトコルのどちらかであるかもしれません。
If a packet is received that does not pass the authentication check due to a missing authentication header or incorrect message digest, then the packet MUST be discarded. The contents of the Authentication Data field should be set to zero on transmission and ignored on reception.
パケットが受け取られているなら、それは行方不明の認証ヘッダーか不正確なメッセージダイジェストによる認証チェックを通過しないで、次に、パケットを捨てなければなりません。 Authentication Data分野のコンテンツは、トランスミッションのときにゼロに設定されて、レセプションで無視されるべきです。
Knight, et. al. Standards Track [Page 12] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[12ページ]。
5.3.7 Advertisement Interval (Adver Int)
5.3.7 広告間隔(Adver Int)
The Advertisement interval indicates the time interval (in seconds) between ADVERTISEMENTS. The default is 1 second. This field is used for troubleshooting misconfigured routers.
Advertisement間隔はADVERTISEMENTSの間に時間間隔を示します(秒に)。 デフォルトは1秒です。 この分野は、misconfiguredルータを障害調査するのに使用されます。
5.3.8 Checksum
5.3.8 チェックサム
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. For computing the checksum, the checksum field is set to zero.
チェックサムはバージョン野原から始まる全体のVRRPメッセージの1の補数合計の16ビットの1の補数です。 チェックサムを計算するのにおいて、チェックサム分野はゼロに設定されます。
5.3.9 IP Address(es)
5.3.9 IPアドレス(es)
One or more IP addresses that are associated with the virtual router. The number of addresses included is specified in the "Count IP Addrs" field. These fields are used for troubleshooting misconfigured routers.
IPがそれを扱う1つか以上が仮想のルータに関連しています。 アドレスを含む数は「カウントIP Addrs」分野で指定されます。 これらの分野は、misconfiguredルータを障害調査するのに使用されます。
5.3.10 Authentication Data
5.3.10 認証データ
The authentication string is currently only utilized for simple text authentication, similar to the simple text authentication found in the Open Shortest Path First routing protocol [OSPF]. It is up to 8 characters of plain text. If the configured authentication string is shorter than 8 bytes, the remaining space MUST be zero-filled. Any VRRP packet received with an authentication string that does not match the locally configured authentication string MUST be discarded. The authentication string is unique on a per interface basis.
認証ストリングは現在簡単なテキスト認証に利用されるだけです、オープンShortest Path Firstルーティング・プロトコルで見つけられた簡単なテキスト認証[OSPF]と同様です。 それはプレーンテキストの最大8つのキャラクタです。 構成された認証ストリングが8バイトより脆いなら、残っているスペースは無いっぱいにしなければなりません。 局所的に構成された認証ストリングに合っていない認証ひもで受け取られたどんなVRRPパケットも捨てなければなりません。 認証ストリングはインタフェース基礎あたりのaでユニークです。
There is no default value for this field.
この分野へのデフォルト値が全くありません。
6. Protocol State Machine
6. プロトコル州のマシン
6.1 Parameters
6.1 パラメタ
6.1.1 Parameters per Interface
6.1.1 1インタフェースあたりのパラメタ
Authentication_Type Type of authentication being used. Values
are defined in section 5.3.6.
使用される認証の認証_Type Type。 値はセクション5.3.6で定義されます。
Authentication_Data Authentication data specific to the
Authentication_Type being used.
使用されるAuthentication_Typeに特定の認証_Data Authenticationデータ。
Knight, et. al. Standards Track [Page 13] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[13ページ]。
6.1.2 Parameters per Virtual Router
6.1.2 仮想のルータあたりのパラメタ
VRID Virtual Router Identifier. Configured item
in the range 1-255 (decimal). There is no
default.
VRIDの仮想のルータ識別子。 範囲1-255(小数)における構成された項目。 デフォルトが全くありません。
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 IP
addresses associated with the virtual
router. The value of 0 (zero) is reserved
for 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. The default value is 100
(decimal).
Priorityがこの仮想のルータにこのVRRPルータによってMaster選挙に使用されるために評価する優先権。 255(10進)の値は仮想のルータに関連しているIPアドレスを所有しているルータのために予約されます。 Masterルータが、仮想のルータへの責任をリリースしているのを示すように、0(ゼロ)の値は予約されます。 範囲1-254(小数)は仮想のルータを支援するVRRPルータに利用可能です。 デフォルト値は100(10進)です。
IP_Addresses One or more IP addresses associated with
this virtual router. Configured item. No
default.
Addresses Oneか、より多くのIPが扱うIP_はこの仮想のルータと交際しました。 構成された項目。 デフォルトがありません。
Advertisement_Interval Time interval between ADVERTISEMENTS
(seconds). Default is 1 second.
ADVERTISEMENTS(秒)の広告_Interval Time間隔。 デフォルトは1秒です。
Skew_Time Time to skew Master_Down_Interval in
seconds. Calculated as:
秒に斜行Master_Down_Intervalに_Time Timeを歪曲してください。 以下として計算されました。
( (256 - Priority) / 256 )
((256--優先権)/256)
Master_Down_Interval Time interval for Backup to declare Master
down (seconds). Calculated as:
_Down_Interval Time間隔をマスタリングして、Backupは(秒)にMasterを申告してください。 以下として計算されました。
(3 * Advertisement_Interval) + Skew_time
(3*広告_間隔)+斜行_時間
Preempt_Mode Controls whether a higher priority Backup
router preempts a lower priority Master.
Values are True to allow preemption and
False to not prohibit preemption. Default
is True.
より高い優先権Backupルータが低優先度Masterを先取りするか否かに関係なく、_Mode Controlsを先取りしてください。 値は先取りとFalseが先取りを禁止しないのを許容するTrueです。 デフォルトはTrueです。
Note: Exception is that the router that owns
the IP address(es) associated with the
virtual router always pre-empts independent
of the setting of this flag.
以下に注意してください。 例外は仮想のルータに関連しているIPアドレス(es)を所有しているルータがいつもこの旗の設定の独立者を先取りするということです。
Knight, et. al. Standards Track [Page 14] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[14ページ]。
6.2 Timers
6.2 タイマ
Master_Down_Timer Timer that fires when ADVERTISEMENT has not
been heard for Master_Down_Interval.
_がADVERTISEMENTがMaster_Down_Intervalに関して聞かれていないとき発火するDown_Timer Timerであるとマスタリングしてください。
Adver_Timer Timer that fires to trigger sending of
ADVERTISEMENT based on
Advertisement_Interval.
ADVERTISEMENTの発信の引き金となるように発火するAdver_Timer Timerが_IntervalをAdvertisementに基礎づけました。
6.3 State Transition Diagram
6.3状態遷移ダイヤグラム
+---------------+
+--------->| |<-------------+
| | Initialize | |
| +------| |----------+ |
| | +---------------+ | |
| | | |
| V V |
+---------------+ +---------------+
| |---------------------->| |
| Master | | Backup |
| |<----------------------| |
+---------------+ +---------------+
+---------------+ +--------->| | <、-、-、-、-、-、-、-、-、-、-、-、--+ | | 初期化します。| | | +------| |----------+ | | | +---------------+ | | | | | | | V V| +---------------+ +---------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| マスター| | バックアップ| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +---------------+ +---------------+
6.4 State Descriptions
6.4 州の記述
In the state descriptions below, the state names are identified by
{state-name}, and the packets are identified by all upper case
characters.
以下での州の記述では、州の名は州名によって特定されます、そして、パケットはすべての大文字キャラクタによって特定されます。
A VRRP router implements an instance of the state machine for each virtual router election it is participating in.
VRRPルータはそれが参加しているそれぞれの仮想のルータ選挙のための州のマシンのインスタンスを実装します。
6.4.1 Initialize
6.4.1、初期化
The purpose of this state is to wait for a Startup event. If a Startup event is received, then:
この状態の目的はStartupイベントを待つことです。 次に、Startupイベントを受け取るなら:
- If the Priority = 255 (i.e., the router owns the IP address(es)
associated with the virtual router)
- 優先権が255と等しいなら(すなわち、ルータは仮想のルータに関連しているIPアドレス(es)を所有しています)
o Send an ADVERTISEMENT
o Broadcast a gratuitous ARP request containing the virtual
router MAC address for each IP address associated with the
virtual router.
o Set the Adver_Timer to Advertisement_Interval
o Transition to the {Master} state
o マスターへのAdvertisement_Interval o TransitionへのAdver_Timerが述べる仮想のルータ. o Setに関連しているそれぞれのIPアドレスのための仮想のルータMACアドレスを含む無料のARP要求をADVERTISEMENT○Broadcastに送ってください。
Knight, et. al. Standards Track [Page 15] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[15ページ]。
else
ほか
o Set the Master_Down_Timer to Master_Down_Interval
o Transition to the {Backup} state
o バックアップへのMaster_Down_Interval o TransitionへのTimerが述べるMaster_Down_を設定してください。
endif
endif
6.4.2 Backup
6.4.2 バックアップ
The purpose of the {Backup} state is to monitor the availability and
state of the Master Router.
状態があるバックアップの目的はMaster Routerの有用性と州をモニターします。
While in this state, a VRRP router MUST do the following:
VRRPルータはこの状態で以下をしなければなりませんが:
- MUST NOT respond to ARP requests for the IP address(s) associated
with the virtual router.
- 仮想のルータに関連しているIPアドレスを求めるARP要求に応じてはいけません。
- MUST discard packets with a destination link layer MAC address
equal to the virtual router MAC address.
- 仮想のルータMACアドレスと等しい送付先リンクレイヤMACアドレスでパケットを捨てなければなりません。
- MUST NOT accept packets addressed to the IP address(es) associated
with the virtual router.
- IPアドレス(es)に扱われたパケットが仮想のルータに関連していると受け入れてはいけません。
- If a Shutdown event is received, then:
- 次に、Shutdownイベントを受け取るなら:
o Cancel the Master_Down_Timer
o Transition to the {Initialize} state
o Master_Down_Timer o Transitionを取り消す、状態を初期化してください。
endif
endif
- If the Master_Down_Timer fires, then:
- 次に、Master_Down_Timerが発火するなら:
o Send an ADVERTISEMENT
o Broadcast a gratuitous ARP request containing the virtual
router MAC address for each IP address associated with the
virtual router
o Set the Adver_Timer to Advertisement_Interval
o Transition to the {Master} state
o マスターへのAdvertisement_Interval o TransitionへのAdver_Timerが述べる仮想のルータo Setに関連しているそれぞれのIPアドレスのための仮想のルータMACアドレスを含む無料のARP要求をADVERTISEMENT○Broadcastに送ってください。
endif
endif
- If an ADVERTISEMENT is received, then:
- 次に、ADVERTISEMENTを受け取るなら:
If the Priority in the ADVERTISEMENT is Zero, then:
次に、ADVERTISEMENTのPriorityがZeroであるなら:
o Set the Master_Down_Timer to Skew_Time
o マスター_下に_タイマに_時間を歪曲するように設定してください。
else:
ほかに:
Knight, et. al. Standards Track [Page 16] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[16ページ]。
If Preempt_Mode is False, or If the Priority in the
ADVERTISEMENT is greater than or equal to the local
Priority, then:
Preempt_ModeがFalseであるかADVERTISEMENTのIf PriorityがFalse以上である、地方のPriority、その時:
o Reset the Master_Down_Timer to Master_Down_Interval
o マスター_下に_タイマをリセットして、_下に_間隔をマスタリングしてください。
else:
ほかに:
o Discard the ADVERTISEMENT
o 広告を捨ててください。
endif
endif
endif
endif endif endif
6.4.3 Master
6.4.3 マスター
While in the {Master} state the router functions as the forwarding
router for the IP address(es) associated with the virtual router.
マスターにある間、IPのための推進ルータとしてのルータ機能が演説する州(es)は仮想のルータと交際しました。
While in this state, a VRRP router MUST do the following:
VRRPルータはこの状態で以下をしなければなりませんが:
- MUST respond to ARP requests for the IP address(es) associated
with the virtual router.
- 仮想のルータに関連しているIPアドレス(es)を求めるARP要求に応じなければなりません。
- MUST forward packets with a destination link layer MAC address
equal to the virtual router MAC address.
- 仮想のルータMACアドレスと等しい送付先リンクレイヤMACアドレスがあるパケットを進めなければなりません。
- MUST NOT accept packets addressed to the IP address(es) associated
with the virtual router if it is not the IP address owner.
- それがIPアドレス所有者でないならIPアドレス(es)に扱われたパケットが仮想のルータに関連していると受け入れてはいけません。
- MUST accept packets addressed to the IP address(es) associated
with the virtual router if it is the IP address owner.
- それがIPアドレス所有者であるならIPアドレス(es)に扱われたパケットが仮想のルータに関連していると受け入れなければなりません。
- If a Shutdown event is received, then:
- 次に、Shutdownイベントを受け取るなら:
o Cancel the Adver_Timer
o Send an ADVERTISEMENT with Priority = 0
o Transition to the {Initialize} state
o キャンセル、PriorityとADVERTISEMENTが0○Transitionと等しいAdver_Timer o Send、状態を初期化してください。
endif
endif
- If the Adver_Timer fires, then:
- 次に、Adver_Timerが発火するなら:
o Send an ADVERTISEMENT
o Reset the Adver_Timer to Advertisement_Interval
o Advertisement_IntervalへのReset Adver_TimerをADVERTISEMENT oに送ってください。
endif
endif
Knight, et. al. Standards Track [Page 17] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[17ページ]。
- If an ADVERTISEMENT is received, then:
- 次に、ADVERTISEMENTを受け取るなら:
If the Priority in the ADVERTISEMENT is Zero, then:
次に、ADVERTISEMENTのPriorityがZeroであるなら:
o Send an ADVERTISEMENT
o Reset the Adver_Timer to Advertisement_Interval
o Advertisement_IntervalへのReset Adver_TimerをADVERTISEMENT oに送ってください。
else:
ほかに:
If the Priority in the ADVERTISEMENT is greater than the
local Priority,
or
If the Priority in the ADVERTISEMENT is equal to the local
Priority and the primary IP Address of the sender is greater
than the local primary IP Address, then:
ADVERTISEMENTのADVERTISEMENTのPriorityが地方のPriorityより大きいか、そして、If Priorityは地方のPriorityと等しいです、そして、送付者のプライマリIP Addressは地方のプライマリIP Addressより優れています、そして:
o Cancel Adver_Timer
o Set Master_Down_Timer to Master_Down_Interval
o Transition to the {Backup} state
o バックアップへのMaster_Down_Interval o TransitionへのDown_Timerが述べるAdver_Timer o Set Master_を取り消してください。
else:
ほかに:
o Discard ADVERTISEMENT
o 広告を捨ててください。
endif
endif
endif
endif endif endif
7. Sending and Receiving VRRP Packets
7. 送受信VRRPパケット
7.1 Receiving VRRP Packets
7.1 VRRPパケットを受けること。
Performed the following functions when a VRRP packet is received:
VRRPパケットが受け取られているとき、以下の機能を実行します:
- MUST verify that the IP TTL is 255.
- MUST verify the VRRP version
- MUST verify that the received packet length is greater than or
equal to the VRRP header
- MUST verify the VRRP checksum
- MUST perform authentication specified by Auth Type
- IP TTLが255歳であることを確かめなければなりません。 - VRRPバージョン--容認されたパケット長がVRRPヘッダー--VRRPチェックサムについて確かめなければなりません--認証を実行しなければならないのがAuth Typeで、より指定したということであることを確かめなければならないことを確かめなければなりません。
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はイベントを登録します、そして、誤りが発生したのをネットワークマネージメントで示すかもしれません。
- MUST verify that the VRID is valid on the receiving interface
- VRIDが受信インタフェースで有効であることを確かめなければなりません。
If the above check fails, the receiver MUST discard the packet.
上のチェックが失敗するなら、受信機はパケットを捨てなければなりません。
Knight, et. al. Standards Track [Page 18] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[18ページ]。
- MAY verify that the IP address(es) associated with the VRID are
valid
- VRIDに関連しているIPアドレス(es)が有効であることを確かめるかもしれません。
If the above check fails, the receiver SHOULD log the event and MAY indicate via network management that a misconfiguration was detected. If the packet was not generated by the address owner (Priority does not equal 255 (decimal)), the receiver MUST drop the packet, otherwise continue processing.
上のチェックが失敗するなら、受信機SHOULDはイベントを登録します、そして、misconfigurationが検出されたのをネットワークマネージメントで示すかもしれません。 パケットがアドレス所有者によって生成されなかったなら(優先権は255(10進)と等しくはありません)、受信機はパケットを下げなければなりません。さもなければ、処理し続けてください。
- MUST verify that the Adver Interval in the packet is the same as
the locally configured for this virtual router
- パケットのAdver Intervalがこの仮想のルータのために局所的に構成されているのと同じであることを確かめなければなりません。
If the above check fails, the receiver MUST discard the packet, SHOULD log the event and MAY indicate via network management that a misconfiguration was detected.
上のチェックが失敗するなら、受信機はパケットを捨てなければなりません、そして、SHOULDはイベントを登録します、そして、misconfigurationが検出されたのをネットワークマネージメントで示すかもしれません。
7.2 Transmitting VRRP Packets
7.2 VRRPパケットを伝えること。
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
- Compute the VRRP checksum
- Set the source MAC address to Virtual Router MAC Address
- Set the source IP address to interface primary IP address
- Set the IP protocol to VRRP
- Send the VRRP packet to the VRRP IP multicast group
- 適切な仮想のルータ構成状態と共にVRRPパケット分野に記入してください--VRRPチェックサムを計算してください--ソースMACアドレスをVirtual Routerマックーアドレスに設定してください--ソースIPアドレスにプライマリIPアドレスを連結するように設定してください--IPプロトコルをVRRPに設定してください--VRRP IPマルチキャストグループにVRRPパケットを送ってください。
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セグメントを決定するのを保証します。
7.3 Virtual Router MAC Address
7.3 仮想のルータマックーアドレス
The virtual router MAC address associated with a virtual router is an IEEE 802 MAC Address in the following format:
仮想のルータに関連している仮想のルータMACアドレスは以下の形式のIEEE802マックーアドレスです:
00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)
00-00-5 E-00-01VRID(インターネットの標準のビットオーダーにおける十六進法における)
The first three octets are derived from the IANA's OUI. The next two
octets (00-01) indicate the address block assigned to the VRRP
protocol. {VRID} is the VRRP Virtual Router Identifier. This
mapping provides for up to 255 VRRP routers on a network.
IANAのOUIから最初の3つの八重奏を得ます。 次の2つの八重奏(00-01)がVRRPプロトコルに割り当てられたあて先ブロックを示します。 VRIDはVRRP Virtual Router Identifierです。 このマッピングはネットワークの255のVRRPルータまで提供されます。
Knight, et. al. Standards Track [Page 19] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[19ページ]。
8. Operational Issues
8. 操作上の問題
8.1 ICMP Redirects
ICMPが向け直す8.1
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 Redirectsは使用されるかもしれません。 これは、トポロジーが左右対称でないところにVRRPが環境で使用されるのを許容します。
The IP source address of an ICMP redirect should be the address 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のソースアドレスが向け直すIPは次のホップルーティング決定をするとき終わりのホストが使用したアドレスであるべきです。 再直接のソースアドレスを選択するとき、それが所有していないアドレスを含んでいて、VRRPルータが仮想のルータのためのMasterとして機能しているなら、それは、パケットがどの仮想のルータに送られたかを決定しなければなりません。 使用される仮想のルータを推論する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が左右対称のトポロジーの多くのルータの間のシェアトラフィックをロードするのに使用されている特定のケースのためにRedirectsを無効にするのは役に立つかもしれません。
8.2 Host ARP Requests
8.2 ホストARP要求
When a host sends an ARP request for one of the virtual router IP addresses, the Master virtual router MUST respond to the ARP request with the virtual MAC address for the virtual router. The Master virtual router 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.
ホストが仮想のルータIPアドレスの1つを求めるARP要求を送るとき、Masterの仮想のルータは仮想のルータのための仮想のMACアドレスでARP要求に応じなければなりません。 Masterの仮想のルータは物理的なMACアドレスで応じてはいけません。 これで、クライアントは現在のMasterルータにかかわらずいつも同じMACアドレスを使用できます。
When a VRRP router restarts or boots, it SHOULD not send any ARP messages with its physical MAC address for the IP address it owns, it should only send ARP messages that include Virtual MAC addresses. This may entail:
VRRPルータがいつ再開するか、そして、ブーツ、それ、SHOULDはそれが所有しているIPアドレスへの物理的なMACアドレスがあるどんなARPメッセージも送らないで、それはVirtual MACアドレスを含んでいるメッセージをARPに送るだけであるべきです。 これは以下を伴うかもしれません。
- When configuring an interface, VRRP routers should broadcast a
gratuitous ARP request containing the virtual router MAC address
for each IP address on that interface.
- インタフェースを構成するとき、VRRPルータはそのインタフェースに関するそれぞれのIPアドレスのための仮想のルータMACアドレスを含む無料のARP要求を放送するべきです。
- At system boot, when initializing interfaces for VRRP operation;
delay gratuitous ARP requests and ARP responses until both the IP
address and the virtual router MAC address are configured.
- システムブートで(その時初期値設定はVRRP操作のために連結します)。 IPアドレスと仮想のルータMACアドレスの両方が構成されるまで、無料のARP要求とARP応答を遅らせてください。
8.3 Proxy ARP
8.3 プロキシARP
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.
Proxy ARPがVRRPルータで使用されるつもりであるなら、VRRPルータはProxy ARPメッセージのVirtual Router MACアドレスの広告を出さなければなりません。 別の方法でするのはホストにVRRPルータの本当のMACアドレスを学ばせることができました。
Knight, et. al. Standards Track [Page 20] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[20ページ]。
9. Operation over FDDI and Token Ring
9. FDDIとトークンリングの上の操作
9.1 Operation over FDDI
9.1 FDDIの上の操作
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が1つ以上のMasterルータをあるかもしれません。 Masterルータがハードウェア・アドレスとして仮想のルータMACアドレスをFDDIデバイスにインストールすると、他のマスターズのADVERTISEMENTSはMaster集合の間、リングから取り外されるでしょう、そして、集合は失敗するでしょう。
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.
これを避けるために、実装SHOULDはハードウェアMACアドレスを変えるよりFDDIデバイスでむしろユニキャストMACフィルタを加えることによって、仮想のルータMACアドレスを構成します。 これは、Masterルータがそれが溯源しなかった少しのADVERTISEMENTSも取り外すのを防ぐでしょう。
9.2 Operation over Token Ring
9.2 トークンリングの上の操作
Token ring has several characteristics which make running VRRP difficult. These include:
トークンリングには、実行しているVRRPを難しくするいくつかの特性があります。 これらは:
- 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.
- 送信元経路ブリッジを使用するとき、前のマスターから異なったブリッジトークンリングセグメントに位置する新しいマスターに切り替わるように、メカニズムがキャッシュされたソース経由地案内をアップデートするのに必要です。
- No general multicast mechanism 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.
- どんな一般的なマルチキャストメカニズムも古くて新しいトークンリングアダプターの向こう側に実装をサポートしませんでした。 多くの、より新しいトークンリングアダプターサポートグループアドレスである間、トークンリング機能アドレスサポートは唯一の一般に利用可能なマルチキャストメカニズムです。 トークンリング機能アドレスの限られた数のため、これらは同じトークンリング機能アドレスの他の用法と衝突するかもしれません。
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 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-IP protocols using the same functional address. Since the Novell IPX [IPX] protocol uses
これらの困難のため、トークンリングの上の操作の最もよく使われる方法はVRIDの仮想のMACアドレスにトークンリング機能アドレスを使用することでしょう。 トークンリング機能アドレスで、最初のMACアドレス八重奏における2高位のビットがB'1'にセットします。 彼らは03-00-00-00-00-80〜03-00-02-00-00-00(正準な形式)まで及びます。 しかしながら、1ビット位置あたり1つのユニークな機能アドレスしかマルチキャストアドレスと異なっていません。 機能アドレスアドレス03-00-00-10-00-00〜03-00-02-00-00-00はユーザによって定義されたアプリケーションのためにToken Ring Architecture[TKARCH]によって予約されます。 しかしながら、12のユーザによって定義されたトークンリング機能アドレスしかないので、同じ機能アドレスを使用する他の非IPプロトコルがあるかもしれません。 ノベルIPX[IPX]プロトコル用途以来
Knight, et. al. Standards Track [Page 21] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[21ページ]。
the 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- IP 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.
VRIDsは直接トークンリング機能アドレスに写像されます。 機能アドレス闘争の見込みを減少させるために、配分は最も大きい機能アドレスで始まるでしょう。 ほとんどの非IPのプロトコルが1番目を使用するか、ユーザによって定義された機能アドレスが最初に、結合されて、または1から始まって、VRRPユーザがVRIDsを連続して選ぶと予想されます。
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
VRIDトークンリング機能アドレス---- ----------------------------- 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は正典外の形式において(0×4000>>(VRID--1))と等しいです。
Since a functional address cannot be used 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 [802.1D].
MACの平らなソースアドレスとして使用されていた状態で機能アドレスを使用できないので、本当のMACアドレスはMACソースアドレスとしてVRRP広告で使用されます。 スパニングツリー探検家経路[802.1D]で機能アドレスに扱われたパケットを送るので、これはブリッジのための問題ではありません。
The functional address mode of operation MUST be implemented by routers supporting VRRP on token ring.
トークンリングの上でVRRPをサポートするルータで機能アドレス運転モードを実装しなければなりません。
Additionally, routers MAY support unicast mode of operation to take advantage of newer token ring adapter implementations which 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. ARP 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 ARP cache.
さらに、ルータは、複数のユニキャストMACアドレスのために非無差別なレセプションをサポートするより新しいトークンリングアダプター実装を利用して、マルチキャストトラフィックと用法闘争のトークンリング機能アドレスの使用に関連している両方を避けるためにユニキャスト運転モードをサポートするかもしれません。 ユニキャストモードはイーサネットとして仮想のMACアドレスにVRIDsに関する同じマッピングを使用します。 しかしながら、1つの重要な違いが存在しています。 ARP要求/回答パケットはソースMACアドレスとして仮想のMACアドレスを含んでいます。 この理由はいくつかのトークンリングドライバー実装がARPキャッシュの如何にかかわらずMACアドレス/ソースルーティング情報のキャッシュを保つということです。
Knight, et. al. Standards Track [Page 22] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[22ページ]。
Hence, these implementations need 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 which should be considered. If there are VRID routers on different source-route bridge segments and there are host implementations which keep their source-route information in the ARP cache and do not listen to gratuitous ARPs, these hosts will not update their ARP source-route information correctly when a switch-over occurs. The only possible solution is to put all routers with the same VRID on the same source- bridge segment and use techniques to prevent that bridge segment from being a single point of failure. These techniques are beyond the scope this document.
トークンリングのユニキャストモードには、考えられるべきである1つの制限があります。 VRIDルータが異なった送信元経路ブリッジセグメントにあって、ARPキャッシュにおけるそれらの送信元経路情報を保って、無料のARPsを聞かないホスト導入があると、オーバースイッチが現れる場合、これらのホストは正しく彼らのARP送信元経路情報をアップデートしないでしょう。 唯一の可能なソリューションは、同じVRIDがあるすべてのルータを同じソースブリッジセグメントに置いて、そのブリッジセグメントが1ポイントの失敗であることを防ぐのにテクニックを使用することです。 これらのテクニックは範囲を超えてこのドキュメントです。
For both the multicast and unicast mode of operation, VRRP advertisements sent to 224.0.0.18 should be encapsulated as described in [RFC1469].
マルチキャストとユニキャスト運転モードの両方に関しては、VRRP広告は.18が[RFC1469]で説明されるようにカプセル化されるべきである.0を224.0に送りました。
10. Security Considerations
10. セキュリティ問題
VRRP is designed for a range of internetworking environments that may employ different security policies. The protocol includes several authentication methods ranging from no authentication, simple clear text passwords, and strong authentication using IP Authentication with MD5 HMAC. The details on each approach including possible attacks and recommended environments follows.
VRRPは異なった安全保障政策を使うかもしれないさまざまなインターネットワーキング環境のために設計されています。 プロトコルは、MD5 HMACとIP Authenticationを使用することで認証がないのから変化するいくつかの認証方法、簡単なクリアテキストパスワード、および強い認証を含んでいます。 可能な攻撃とお勧めの環境を含んでいると続く各アプローチに関する詳細。
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を設定する)を含んでいます。 これはほとんどの脆弱性を地方の攻撃に制限します。
10.1 No Authentication
10.1 認証がありません。
The use of this authentication type means that VRRP protocol exchanges are not authenticated. This type of authentication SHOULD only be used in environments were there is minimal security risk and little chance for configuration errors (e.g., two VRRP routers on a LAN).
この認証タイプの使用は、VRRPプロトコル交換が認証されないことを意味します。 これをタイプします。環境で使用されているのが、最小量のセキュリティリスクと見込みが構成誤り(例えば、LANに関する2つのVRRPルータ)によってほとんどないということであったという認証SHOULDだけでは、ことになってください。
10.2 Simple Text Password
10.2 簡単なテキストパスワード
The use of this authentication type means that VRRP protocol exchanges are authenticated by a simple clear text password.
この認証タイプの使用は、VRRPプロトコル交換が簡単なクリアテキストパスワードによって認証されることを意味します。
Knight, et. al. Standards Track [Page 23] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[23ページ]。
This type of authentication is useful to protect against accidental misconfiguration of routers on a LAN. It protects against routers inadvertently backing up another router. A new router must first be configured with the correct password before it can run VRRP with another router. This type of authentication does not protect against hostile attacks where the password can be learned by a node snooping VRRP packets on the LAN. The Simple Text Authentication combined with the TTL check makes it difficult for a VRRP packet to be sent from another LAN to disrupt VRRP operation.
このタイプの認証は、LANでルータの偶然のmisconfigurationから守るために役に立ちます。 それはうっかり別のルータを支援するルータから守ります。 別のルータでVRRPを実行できる前に最初に、正しいパスワードで新しいルータを構成しなければなりません。 ノードがパスワードについて学習できるところでこのタイプの認証は、LANでVRRPパケットについて詮索しながら、敵対的な攻撃から守りません。 TTLチェックに結合されたSimple Text AuthenticationはVRRP操作を中断するために別のLANからVRRPパケットを送るのを難しくします。
This type of authentication is RECOMMENDED when there is minimal risk of nodes on a LAN actively disrupting VRRP operation. If this type of authentication is used the user should be aware that this clear text password is sent frequently, and therefore should not be the same as any security significant password.
活発にVRRP操作を中断するLANのノードの最小量のリスクがあるとき、このタイプの認証はRECOMMENDEDです。 このタイプの認証が使用されているなら、ユーザは、このクリアテキストパスワードが頻繁に送られるのを意識しているべきであり、したがって、どんなセキュリティの重要なパスワードとも同じであるべきではありません。
10.3 IP Authentication Header
10.3 IP認証ヘッダー
The use of this authentication type means the VRRP protocol exchanges are authenticated using the mechanisms defined by the IP Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP and AH", [HMAC]. This provides strong protection against configuration errors, replay attacks, and packet corruption/modification.
そして、この認証タイプの使用が、VRRPプロトコル交換がIP Authentication Header[AUTH]使用で定義されたメカニズムを使用することで認証されることを意味する、「超能力の中のHMAC-MD5-96の使用、ああ、」、[HMAC。] これは構成誤り、反射攻撃、およびパケット不正/変更に対する強い保護を提供します。
This type of authentication is RECOMMENDED when there is limited control over the administration of nodes on a LAN. While this type of authentication does protect the operation of VRRP, there are other types of attacks that may be employed on shared media links (e.g., generation of bogus ARP replies) which are independent from VRRP and are not protected.
LANのノードの管理の限られたコントロールがあるとき、このタイプの認証はRECOMMENDEDです。 このタイプの認証はVRRPの操作を保護しますが、VRRPから独立している共有されたメディアリンク(例えば、にせのARP回答の世代)の上に使われるかもしれなくて、保護されない他のタイプの攻撃があります。
11. Acknowledgments
11. 承認
The authors would like to thank Glen Zorn, and Michael Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve Bellovin, and Thomas Narten for their comments and suggestions.
作者は彼らのコメントと提案についてGlenゾルン、マイケル・レイン、クラーク・ブリーマー、ハル・ピーターソン、トニー・李、バーバラ・デニー、ジョエル・アルペルン、スティーブBellovin、およびトーマスNartenに感謝したがっています。
12. References
12. 参照
[802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std
802.1D, 1993 edition.
[802.1D]世界規格ISO/IEC10038: 1993 ANSI/IEEE Std 802.1D、1993年の版。
[AUTH] Kent, S., and R. Atkinson, "IP Authentication Header",
Work in Progress.
[AUTH] ケント、S.とR.アトキンソン、「IP認証ヘッダー」、進行中で、働いてください。
[DISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[ディスク] デアリング、S.、「ICMPルータ発見メッセージ」、RFC1256、1991年9月。
Knight, et. al. Standards Track [Page 24] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[24ページ]。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[DHCP] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[HMAC] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", Work in Progress.
そして、[HMAC] マドソン、C.、およびR.グレン、「超能力の中のHMAC-MD5-96の使用、ああ、」 仕事進行中です。
[HSRP] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby
Router Protocol (HSRP)", RFC 2281, March 1998.
[HSRP] 1998年の李、T.、コール、B.、モートン、P.、およびD.李、「コクチマスホット・スタンバイ機能ルータプロトコル(HSRP)」、RFC2281行進。
[IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to
Provide Fast Failover in IP Networks", Digital Technical
Journal, Volume 9 Number 3, Winter 1997.
[IPSTB]ヒギンソン、P.、M.シャンド、「ルータの開発は速いフェイルオーバーをIPネットワークに提供するためにクラスタリングします」、デジタル専門誌、第9巻のNo.3、1997年冬。
[IPX] Novell Incorporated., "IPX Router Specification", Version
1.10, October 1992.
[IPX]ノベルが法人組織にした、「IPXルータ仕様」、バージョン1.10、10月1992
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RIP] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[裂きます] ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、1988年6月。
[RFC1469] Pusateri, T., "IP over Token Ring LANs", RFC 1469, June
1993.
[RFC1469]Pusateri、1993年6月のT.、「トークンリングLANの上のIP」RFC1469。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[TKARCH] IBM Token-Ring Network, Architecture Reference, Publication
SC30-3374-02, Third Edition, (September, 1989).
[TKARCH]IBMトークンリングネットワーク、アーキテクチャ参照、公表SC30-3374-02、第3版(1989年9月)。
13. Authors' Addresses
13. 作者のアドレス
Steven Knight Phone: +1 612 943-8990 Ascend Communications EMail: Steven.Knight@ascend.com High Performance Network Division 10250 Valley View Road, Suite 113 Eden Prairie, MN USA 55344 USA
スティーブンナイト電話: +1 612 943-8990 コミュニケーションメールを昇ってください: Steven.Knight@ascend.com 高性能ネットワーク区画10250バレー視点道路、スイート113エデン大草原、ミネソタ米国米国55344
Douglas Weaver Phone: +1 612 943-8990 Ascend Communications EMail: Doug.Weaver@ascend.com High Performance Network Division 10250 Valley View Road, Suite 113 Eden Prairie, MN USA 55344 USA
ダグラスウィーバーPhone: +1 612 943-8990 コミュニケーションメールを昇ってください: Doug.Weaver@ascend.com 高性能ネットワーク区画10250バレー視点道路、スイート113エデン大草原、ミネソタ米国米国55344
Knight, et. al. Standards Track [Page 25] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[25ページ]。
David Whipple Phone: +1 206 703-3876 Microsoft Corporation EMail: dwhipple@microsoft.com One Microsoft Way Redmond, WA USA 98052-6399 USA
デヴィッドホイップルPhone: +1 206 703-3876マイクロソフト社メール: dwhipple@microsoft.com 1マイクロソフトWayワシントンレッドモンド(米国)98052-6399米国
Robert Hinden Phone: +1 408 990-2004 Nokia EMail: hinden@iprg.nokia.com 232 Java Drive Sunnyvale, CA 94089 USA
ロバートHindenは以下に電話をします。 +1 408 990-2004ノキアメール: hinden@iprg.nokia.com 232Java Driveカリフォルニア94089サニーベル(米国)
Danny Mitzel Phone: +1 408 990-2037 Nokia EMail: mitzel@iprg.nokia.com 232 Java Drive Sunnyvale, CA 94089 USA
ダニーMitzelは以下に電話をします。 +1 408 990-2037ノキアメール: mitzel@iprg.nokia.com 232Java Driveカリフォルニア94089サニーベル(米国)
Peter Hunt Phone: +1 408 990-2093 Nokia EMail: hunt@iprg.nokia.com 232 Java Drive Sunnyvale, CA 94089 USA
ピーター狩り電話: +1 408 990-2093ノキアメール: hunt@iprg.nokia.com 232Java Driveカリフォルニア94089サニーベル(米国)
P. Higginson Phone: +44 118 920 6293 Digital Equipment Corp. EMail: higginson@mail.dec.com Digital Park Imperial Way Reading Berkshire RG2 0TE UK
P.ヒギンソン電話: +44 6293年の118 920ディジタル・イクイップメント社メール: バークシャーRG2 0TEイギリスを読む higginson@mail.dec.com のデジタル公園帝国の道
M. Shand Phone: +44 118 920 4424 Digital Equipment Corp. EMail: shand@mail.dec.com Digital Park Imperial Way Reading Berkshire RG2 0TE UK
M.シャンド電話: +44 4424年の118 920ディジタル・イクイップメント社メール: バークシャーRG2 0TEイギリスを読む shand@mail.dec.com のデジタル公園帝国の道
Acee Lindem Phone: 1-919-254-1805 IBM Corporation E-Mail: acee@raleigh.ibm.com P.O. Box 12195 Research Triangle Park, NC 27709 USA
Acee Lindemは以下に電話をします。 1-919-254-1805 IBM社のメール: acee@raleigh.ibm.com 私書箱12195リサーチトライアングル公園、NC27709米国
Knight, et. al. Standards Track [Page 26] RFC 2338 VRRP April 1998
etナイト、アル。 規格はVRRP1998年4月にRFC2338を追跡します[26ページ]。
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Knight, et. al. Standards Track [Page 27]
etナイト、アル。 標準化過程[27ページ]
一覧
スポンサーリンク
