rfc2281.txt

RFC 的详细文档！

+-----+----------+----------+----------+----------+----------+----------+
|  f  |          |          |          |   B/3    |   B/3    |          |
+-----+----------+----------+----------+----------+----------+----------+
|  g  |          |   EAB/3  |    EA    |   EA     |   EA     |   AB/4   |
+-----+----------+----------+----------+----------+----------+----------+
|  h  |          |   EAB/3  | A|BGFI/6*| A|BGFI/6*| A|BGFI/6*|    G     |
+-----+----------+----------+----------+----------+----------+----------+
|  i  |          |          |   AB/4   |   A      |  CFI/6   |          |
+-----+----------+----------+----------+----------+----------+----------+
|  j  |          |          |          |          |          |   ABH/4  |
+-----+----------+----------+----------+----------+----------+----------+
|  k  |          |          |    B     |   B/3    |  B/3     |    B     |
+-----+----------+----------+----------+----------+----------+----------+
|  l  |          |          |    B/4   |   D/5    |          |    B     |
+-----+----------+----------+----------+----------+----------+----------+

   Notes

   +   If the virtual IP address is configured, set state 3 (Listen) If
   the virtual IP address is not configured, set state 2 (Learn).  In
   either case do actions A and B.

   *   If the router is configured to preempt do actions B, G, F, and I
   and set state to 6 (Active).  If the router is not configured to
   preempt do actions A with no state change.










Li, et. al.                  Informational                     [Page 12]

RFC 2281                       Cisco HSRP                     March 1998


6  MAC Address Considerations

6.1 General

   Each HSRP group has an associated well known virtual MAC address.  On
   token ring networks, these addresses are actually functional
   addresses.  The three addresses 0xC0 0x00 0x00 0x01 0x00 0x00, 0xC0
   0x00 0x00 0x02 0x00 0x00, and 0xC0 0x00 0x00 0x04 0x00 0x00
   correspond to groups 0, 1, and 2 respectively.

   On other media, the virtual MAC addresses are 0x00 0x00 0x0C 0x07
   0xAC XX where XX represents the HSRP group number.  Routers which
   implement HSRP SHOULD use well-known HSRP MAC addresses as the
   group's virtual MAC address whenever possible.

   The active router MUST accept and forward traffic that is destined
   for the group's virtual MAC address.  It MUST stop accepting or
   forwarding such traffic when the router leaves the Active state.

   If and only if the router is in the Active state, the router MUST use
   the group's virtual MAC address as the source MAC address for its
   Hello messages.  This is necessary in order to allow learning bridges
   to be able to determine which LAN segment the virtual MAC address
   currently belongs to.

   For each group, there is one virtual IP address and one virtual MAC
   address.  This is a desirable situation, since the ARP table entries
   in the end stations do not need to change over time as the HSRP
   active router moves from one router to another.

   Additionally, for HSRP to work in bridging environments, the bridges
   must be able to quickly update themselves as the virtual MAC address
   "moves".  Although learning bridges typically are able to do this,
   some have been known to have problems with this.  It is RECOMMENDED
   that only true learning bridges be used with HSRP.

   The movement of the virtual MAC address can cause further undesirable
   side effects in environments where additional state is tied to the
   MAC address.  For example on Token Ring, if Source Route Bridging is
   in use, a RIF will be stored with the virtual MAC address in a host's
   RIF cache.  The RIF indicates the path and final ring used to reach
   the MAC address.  As routers transition into Active state, they will
   not be able to affect the RIF caches on the hosts on the bridged
   ring.  This may lead to packets being bridged to the ring for the
   previous active router.






Li, et. al.                  Informational                     [Page 13]

RFC 2281                       Cisco HSRP                     March 1998


   In such circumstances, a router MAY use its normal MAC addresses as
   the virtual MAC address.  This method of operation is strongly
   discouraged.  In this mode, the virtual IP address will map to a
   different MAC address over time.  This can create problems for end
   stations, since ARP tables assume a relatively static mapping between
   MAC address and IP address.  These ARP tables are normally updated
   when the end stations receive the gratuitous ARP responses generated
   by a router that enters the active state.

6.2 Address Filter

   As noted, routers currently emulating a virtual router adopt their
   group's MAC and IP addresses.  MAC addresses are typically provided
   in an address filter or 'list' of MAC addresses in a router's
   interface controller.  It is desirable for routers to be able to add
   one or more virtual MAC addresses to their controllers' MAC address
   filter while maintaining their primary MAC addresses.

   Unfortunately, some interface controllers support address filtering
   for only one unicast MAC address.  Or, in the case of Token Ring, the
   functional address which HSRP should use is already in use for some
   other protocol.  In these cases, such routers can still implement
   HSRP, but the protocol must change the interface's primary MAC
   address when assuming or relinquishing control as the active router.

   This is potentially problematic because some traffic may otherwise
   wish to use the router's primary MAC address.  However, the problem
   MAY be mitigated by having the router send out gratuitous ARP packets
   regarding its non-HSRP IP addresses.  Through this, other network
   entities using IP should update their ARP tables to reflect that the
   router is now using a group virtual MAC address rather than its
   primary MAC address.

   Some protocols may not be able to run simultaneously with the standby
   protocol due to the interface primary MAC address change.  For
   example, DECnet phase IV and HSRP will not be able to run at the same
   time on some equipment.

6.3 ICMP Redirect

   While running HSRP, it is important to prevent the host from
   discovering the primary MAC addresses of the routers in its standby
   group.  Thus, any protocol that informs a host of a router's primary
   address should be disabled.  Thus, routers participating in HSRP on
   an interface MUST NOT send ICMP redirects on that interface.






Li, et. al.                  Informational                     [Page 14]

RFC 2281                       Cisco HSRP                     March 1998


6.4 Proxy ARP

   Typically, hosts learn the HSRP virtual IP address through the
   configuration of their default router.  These hosts then send packets
   for destinations outside of the LAN to the virtual IP address.  In
   some environments, hosts may instead make use of proxy ARP in order
   to route off of the LAN.  In this case, the hosts use the MAC address
   that is supplied in proxy ARP responses.  HSRP functionality is
   maintained if the proxy ARP responses specify the HSRP virtual MAC
   address.

   If an HSRP router is configured to support proxy ARP with HSRP, then
   the router MUST specify the HSRP virtual MAC address in any proxy ARP
   responses it generates.  These proxy ARP responses MUST not be
   suppressed based upon HSRP state.  Suppression based upon state could
   result in lack of any proxy ARP response being generated, since these
   proxy ARP responses may be suppressed due to other reasons, such as
   split-horizon rules.

7. Security Considerations

   This protocol does not provide security.  The authentication field
   found within the message is useful for preventing misconfiguration.
   The protocol is easily subverted by an active intruder on the LAN.
   This can result in a packet black hole and a denial-of-service
   attack.  It is difficult to subvert the protocol from outside the LAN
   as most routers will not forward packets addressed to the all-routers
   multicast address (224.0.0.2).

8. References

   [1] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
   September 1991.

   [2] United States Patent.  Patent Number : 5,473,599.  Standby Router
   Protocol.  Date of Patent: Dec. 5, 1995.

   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.












Li, et. al.                  Informational                     [Page 15]

RFC 2281                       Cisco HSRP                     March 1998


9. Authors' Addresses

   Tony Li
   Juniper Networks, Inc.
   3260 Jay St.
   Santa Clara, CA 95054

   Phone: [phone]
   EMail: [e-mail]


   Bruce Cole
   Juniper Networks, Inc.
   3260 Jay St.
   Santa Clara, CA 95054

   Phone: [phone]
   EMail: [e-mail]


   Phil Morton
   Cisco Systems
   170 Tasman Dr.
   San Jose, CA 95143

   Phone: [phone]
   EMail: [e-mail]


   Dawn Li
   Cisco Systems
   170 Tasman Dr.
   San Jose, CA 95143

   Phone: [phone]
   EMail: [e-mail]















Li, et. al.                  Informational                     [Page 16]

RFC 2281                       Cisco HSRP                     March 1998


10.  Full Copyright Statement

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

   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.
























Li, et. al.                  Informational                     [Page 17]