RFC 3768 - Virtual Router Redundancy Protocol (VRRP)

时间:2006-10-30 来源: 作者: 点击:
NetworkWorkingGroupR.Hinden,Ed. RequestforComments:3768Nokia Obsoletes:2338April2004 Category:StandardsTrack VirtualRouterRedundancyProtocol(VRRP) StatusofthisMemo ThisdocumentspecifiesanInternetstandardstrackprotocolforthe Internetcommunity,andreque
  Network Working Group                                     R. Hinden, Ed.
Request for Comments: 3768                                         Nokia
Obsoletes: 2338                                               April 2004
Category: Standards Track

               Virtual Router Redundancy Protocol (VRRP)

Status of this 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.

Copyright Notice

   Copyright (C) The Internet Society (2004).  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.

Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Contributors. . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Definitions . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Required Features . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.  IP Address Backup . . . . . . . . . . . . . . . . . . .   5
       2.2.  Preferred Path Indication . . . . . . . . . . . . . . .   5
       2.3.  Minimization of Unnecessary Service Disruptions . . . .   5
       2.4.  Efficient Operation over Extended LANs. . . . . . . . .   6
   3.  VRRP Overview . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Sample Configurations . . . . . . . . . . . . . . . . . . . .   7

       4.1.  Sample Configuration 1. . . . . . . . . . . . . . . . .   7
       4.2.  Sample Configuration 2. . . . . . . . . . . . . . . . .   9
   5.  Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . .  10
       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 per Virtual Router . . . . . . . . . . . . .  13
       6.2.  Timers. . . . . . . . . . . . . . . . . . . . . . . . .  14
       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
       8.4.  Potential Forwarding Loop . . . . . . . . . . . . . . .  21
   9.  Operation over FDDI, Token Ring, and ATM LANE . . . . . . . .  21
       9.1.  Operation over FDDI . . . . . . . . . . . . . . . . . .  21
       9.2.  Operation over Token Ring . . . . . . . . . . . . . . .  21
       9.3.  Operation over ATM LANE . . . . . . . . . . . . . . . .  23
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  23
   11. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  24
   12. References. . . . . . . . . . . . . . . . . . . . . . . . . .  24
       12.1. Normative References. . . . . . . . . . . . . . . . . .  24
       12.2. Informative References. . . . . . . . . . . . . . . . .  25
   13. Changes from RFC2338. . . . . . . . . . . . . . . . . . . . .  25
   14. Editor’s Address. . . . . . . . . . . . . . . . . . . . . . .  26
   15. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  27

1.  Introduction

   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.

   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, that 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.

   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.

   VRRP provides a function similar to the proprietary protocols "Hot
   Standby Router Protocol (HSRP)" [HSRP] and "IP Standby Protocol"
   [IPSTB].

   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].

1.1.  Contributors

   The following people, who are the authors of the RFC 2338 that this
   document is based on and replaces, contributed to the text in this
   document.  They are P. Higginson, R. Hinden, P. Hunt, S. Knight, A.
   Lindem, D. Mitzel, M. Shand, D. Weaver, and D. Whipple.  They are not
   listed as authors of the document due to current RFC-Editor policies.

1.2.  Scope

   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.

   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.

1.3.  Definitions

   VRRP Router            A router running the Virtual Router Redundancy
                          Protocol.  It may participate in one or more
                          virtual routers.

   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.

   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.

   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.

   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.

   Virtual Router Backup  The set of VRRP routers available to assume
                          forwarding responsibility for a virtual router
                          should the current Master fail.

2.  Required Features

   This section outlines the set of features that were considered
   mandatory and that guided the design of VRRP.

2.1.  IP Address Backup

   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:

   -  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.

2.2.  Preferred Path Indication

   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.

2.3.  Minimization of Unnecessary Service Disruptions

   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.

   Some environments may find it beneficial to avoid the state
   transition triggered when a router becomes available that is
   preferred over the current Master.  It may be useful to support an
   override of the immediate convergence to the preferred path.

2.4.  Efficient Operation over Extended LANs

   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.

3.  VRRP Overview

   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.

   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.
   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.

   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.

   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.

4.  Sample Configurations

4.1.  Sample Configuration 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.

            +-----------+      +-----------+
            |   Rtr1    |      |   Rtr2    |
            |(MR VRID=1)|      |(BR VRID=1)|
            |           |      |           |
    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

   Eliminating all mention of VRRP (VRID=1) from the figure above leaves
   it as a typical IP deployment.  Each router is permanently assigned
   an IP address on the LAN interface (Rtr1 is assigned IP A and Rtr2 is
   assigned IP B), and each host installs a static default route through
   one of the routers (in this example they all use Rtr1’s IP A).

   Moving to the VRRP environment, each router has the exact same
   permanently assigned IP address.  Rtr1 is said to be the IP address
   owner of IP A, and Rtr2 is the IP address owner of IP B.  A virtual
   router is then defined by associating a unique identifier (the
   virtual router ID) with the address owned by a router.  Finally, the
   VRRP protocol manages virtual router fail over to a backup router.

   The example above shows a virtual router configured to cover the IP
   address owned by Rtr1 (VRID=1,IP_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, since it is not the IP address owner.  If Rtr1
   should fail then the VRRP protocol will transition Rtr2 to Master,
   temporarily taking over forwarding responsibility for IP A to provide
   uninterrupted service to the hosts.

   Note that in this example IP B is not backed up, it is only used by
   Rtr2 as its interface address.  In order to backup IP B, a second
   virtual router must be configured.  This is shown in the next
   section.

4.2.  Sample Configuration 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.

            +-----------+      +-----------+
            |   Rtr1    |      |   Rtr2    |
            |(MR VRID=1)|      |(BR VRID=1)|
            |(BR VRID=2)|      |(MR VRID=2)|
    VRID=1  +-----------+      +-----------+  VRID=2
    IP A ---------->*            *<---------- IP B
                    |            |
                    |            |
  ------------------+------------+-----+--------+--------+--------+--
                                       ^        ^        ^        ^
------分隔线----------------------------
顶一下
(2)
100%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容