draft-ietf-vrrp-spec-v2-05.txt

VRRP双机热备份协议源吗

        packet (including fixed fields, IP Address(es), and
        Authentication Data).
      - MUST verify the VRRP checksum
      - MUST verify that the VRID is configured on the receiving
        interface and the local router is not the IP Address owner
        (Priority equals 255 (decimal)).
      - MUST verify that the Auth Type matches the locally configured
        authentication method for the virtual router and perform that
        authentication method

   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.

      - MAY verify that "Count IP Addrs" and the list of IP Address
        matches the IP_Addresses configured for the VRID

   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.

      - MUST verify that the Adver Interval in the packet is the same as
        the locally configured for this virtual router

   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.


7.2 Transmitting VRRP Packets

   The following operations MUST be performed when transmitting a VRRP
   packet.

      - Fill in the VRRP packet fields with the appropriate virtual
        router configuration state
      - Compute the VRRP checksum



draft-ietf-vrrp-spec-v2-05.txt                                 [Page 20]


INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000


      - 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

   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.


7.3 Virtual Router MAC Address

   The virtual router MAC address associated with a virtual router is an
   IEEE 802 MAC Address in the following format:

      00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)

   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.





























draft-ietf-vrrp-spec-v2-05.txt                                 [Page 21]


INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000


8.  Operational Issues

8.1 ICMP Redirects

   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.

   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.

   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.


8.2  Host ARP Requests

   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.

   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:

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

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


8.3 Proxy 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



draft-ietf-vrrp-spec-v2-05.txt                                 [Page 22]


INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000


   message.  Doing otherwise could cause hosts to learn the real MAC
   address of the VRRP router.


8.4 Potential Forwarding Loop

   A VRRP router SHOULD not forward packets addressed to the IP
   Address(es) it becomes Master for if it is not the owner.  Forwarding
   these packets would result in unnecessary traffic.  Also in the case
   of LANs that receive packets they transmit (e.g., token ring) this
   can result in a forwarding loop that is only terminated when the IP
   TTL expires.

   One such mechanism for VRRP routers is to add/delete a reject host
   route for each adopted IP address when transitioning to/from MASTER
   state.


9.  Operation over FDDI, Token Ring, and ATM LANE

9.1 Operation over 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.

   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.


9.2  Operation over Token Ring

   Token ring has several characteristics that make running VRRP
   difficult. These include:

    - 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



draft-ietf-vrrp-spec-v2-05.txt                                 [Page 23]


INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000


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

   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.

      VRID      Token Ring Functional Address
      ----      -----------------------------
         1             03-00-02-00-00-00
         2             03-00-04-00-00-00
         3             03-00-08-00-00-00
         4             03-00-10-00-00-00
         5             03-00-20-00-00-00
         6             03-00-40-00-00-00
         7             03-00-80-00-00-00
         8             03-00-00-01-00-00
         9             03-00-00-02-00-00
        10             03-00-00-04-00-00
        11             03-00-00-08-00-00

   Or more succinctly, octets 3 and 4 of the functional address are
   equal to (0x4000 >> (VRID - 1)) in non-canonical format.




draft-ietf-vrrp-spec-v2-05.txt                                 [Page 24]


INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000


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

   The functional address mode of operation MUST be implemented by
   routers supporting VRRP on token ring.

   Additionally, routers MAY support unicast mode of operation to take
   advantage of newer token ring adapter implementations that support
   non-promiscuous reception for multiple unicast MAC addresses and to
   avoid both the multicast traffic and usage conflicts associated with
   the use of token ring functional addresses. Unicast mode uses the
   same mapping of VRIDs to virtual MAC addresses as Ethernet.  However,
   one important difference exists. 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.
   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.

   Unicast mode on token ring has one limitation that should be
   considered.  If there are VRID routers on different source-route
   bridge segments and there are host implementations that keep their
   source-route information in the 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.

   For both the multicast and unicast mode of operation, VRRP
   advertisements sent to 224.0.0.18 should be encapsulated as described
   in [RFC1469].


9.3  Operation over ATM LANE

   Operation of VRRP over ATM LANE on routers with ATM LANE interfaces
   and/or routers behind proxy LEC's are beyond the scope of this
   document.







draft-ietf-vrrp-spec-v2-05.txt                                 [Page 25]


INTERNET-DRAFT     Virtual Router Redundancy Protocol    January 5, 2000


10. Security Considerations

   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.

   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.

   The security measures discussed in the following sections only
   provide various kinds of authentication.  No confidentiality is
   provided.  Confidentiality is not necessary for the correct operation
   of VRRP and there is no information in the VRRP messages that must be
   kept secret from other nodes on the LAN.

10.1 No Authentication

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


10.2 Simple Text Password

   The use of this authentication type means that VRRP protocol