INTERNET-DRAFT S. Knight
June 22, 1997 Ascend Communications, Inc.
D. Weaver
Ascend Communications, Inc.
D. Whipple
Microsoft, Inc.
R. Hinden
Ipsilon Networks, Inc.
Virtual Router Redundancy Protocol
<draft-ietf-vrrp-spec-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
This internet draft expires on December 23, 1997.
Abstract
The memo documents the Virtual Router Redundancy Protocol. This is a
protocol which allows several routers to utilize the same virtual IP
address. One router will be elected as a master, with X routers
acting as backups in case of failure of the master router. The
primary advantage to utilizing this protocol, is that host systems
may be configured with a single default gateway, rather than running
draft-ietf-vrrp-spec-00.txt [Page 1]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
an active routing protocol. Each interface on each router within a
VRRP cluster, will be configured with a real IP address, and the
virtual IP address for the particular cluster. Overall, this
protocol adds to the options for providing fault redundancy for
router networks.
Table Of Contents
1. Introduction...............................................3
2. Scope......................................................3
3. Definitions................................................4
4. Sample Configurations......................................4
4.1 Sample Configuration 1................................4
4.2 Sample Configuration 2................................5
5. Protocol...................................................6
5.1 VRRP Packet Format....................................6
5.2 IP Field Descriptions.................................6
5.3 VRRP Field Descriptions...............................7
6. Protocol State Machine.....................................9
6.1 Parameters..............................................9
6.2 Timers.................................................10
6.3 State Transition Diagram..............................10
6.4 State Descriptions....................................10
6.5 State Table...........................................12
7. Sending and Receiving VRRP Packets........................14
7.1 Receiving VRRP Packets................................14
7.2 Transmitting Packets...................................14
7.3 Virtual MAC Address....................................15
8. Host Operation............................................15
8.1 Host ARP Requests....................................15
9. Operational Issues........................................15
9.1 ICMP Redirects.........................................15
9.2 Proxy ARP..............................................15
9.3 Network Management.....................................16
10. Operation over Token Ring.................................16
11. References................................................17
12. Security Considerations...................................17
13. Authors' Addresses........................................17
14. Acknowledgments...........................................17
15. Changes from Previous Drafts..............................18
draft-ietf-vrrp-spec-00.txt [Page 2]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
1. Introduction
The reason for the development of VRRP is to create a standard
protocol, with multi-vendor support to resolve the problem of router
failure. Specifically, when a single router is utilized as a default
gateway, and all hosts are statically configured to this default
gateway, a failure is catastrophic. VRRP resolves this problem by
creating virtual clusters, where each cluster is configured with a
set of member routers. Each member router is either a master router
for the cluster or a backup router for the cluster, but not both
simultaneously. In addition, there MUST only be a single master
router per cluster, at any given time. All member routers are
configured to be part of a cluster, with a given virtual IP address.
This virtual IP address is utilized as the default gateway on all of
the host systems. Given a failure on the current master router, the
next appropriate backup router will become the master router for the
given cluster. When routers are configured with the equal priority
the router which is master will stay master as long as it is up.
Of course this problem could be solved by running a standard routing
protocol such as OSPF, RIP, or RIPv2 on the hosts. However, this is
not always feasible due to either security issues, when hosts are
multihomed, or in some cases implementations of these routing
protocols simply do not exist.
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].
2. Scope
This memo describes the Virtual Router Redundancy Protocol.
This protocol is intended for IPv4 only. A version for IPv6 will be
defined in a separate specification.
Within the scope of this specification are:
1. Packet format and header contents.
2. State Diagrams and Descriptions
3. Network Design Samples
Outside of the scope are
1. Network management
2. Host internal optimizations
draft-ietf-vrrp-spec-00.txt [Page 3]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
3. Definitions
Cluster
Used to describe a set of routers who all have membership to the
set of routers S, where S contains all routers configured with
the same virtual IP address.
Master Router
Used to describe the currently active router, for a particular
cluster, with a particular virtual IP address. Their can only be
one master router in a particular cluster.
Backup Router
Used to describe a router which is configured to act as a backup
for a particular cluster. There can be several backup routers in
a single cluster.
4. Sample Configurations
4.1 Sample Configuration 1
The following figure shows a simple VRRP network.
+--------------------------+
| Cluster X |
| |
| +-----+ +-----+ |
| | MRX | | BRX | |
| +-----+ +-----+ |
Real IP 1 ---------->* *<---------- Real IP 2
| | * | |
+-------------^------------+
| | |
-------------------+------|-----+-----+-------------+------
| ^ ^
Virtual IP --(VIPX)-+ (VIPX) (VIPX)
| |
+--+--+ +--+--+
| H1 | | H2 |
+-----+ +-----+
The above configuration shows the most likely utilization of the VRRP
protocol. In this configuration, the hosts simply point their default
routes at the virtual IP address X (VIPX), and the routers run VRRP
draft-ietf-vrrp-spec-00.txt [Page 4]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
between themselves. The router on the left is the default master
router (MRX), and the router on the right is the backup router (BRX).
Legend: ---+---+---+-- = 802 network, Ethernet or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IP Address
VIP = default gateway for hosts (Virtual IP)
4.2 Sample Configuration 2
The following figure shows a more interesting VRRP network.
+--------------------------+
| Cluster X and Cluster Y |
| |
| +-----+ +-----+ |
| | MRX | | BRX | |
| | & | | & | |
| | BRY | | MRY | |
| +-----+ +-----+ |
Real IP 1 ---------->* *<---------- Real IP 2
| | * * | |
+---------^------^---------+
| | | |
------------------+--|------|--+-----+--------+--------+--------+--
| | ^ ^ ^ ^
Virtual IP --(VIPX)-+ | (VIPX) (VIPY) (VIPX) (VIPY)
| | | | |
Virtual IP --(VIPY)--------+ +--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
In the above configuration, half of the hosts point their default
gateway at cluster X's virtual IP address (VIPX), and half the hosts
point their default gateway at cluster Y's virtual IP address (VIPY).
This has the effect of load balancing the outgoing traffic, while
also providing full redundancy.
Legend: ---+---+---+-- = 802 network, Ethernet or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IP Address
VIP = default gateway for hosts (Virtual IP)
draft-ietf-vrrp-spec-00.txt [Page 5]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
5. Protocol
The purpose of the VRRP packet is to communicate to all other VRRP
routers both the priority and the state of the master's associated
interface.
VRRP packets are sent encapsulated in IP packets. They are sent to
an IPv4 multicast address assigned for VRRP.
5.1 VRRP Packet Format
This section defines the format of the VRRP packet and the relevant
fields in the IP header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 | Version | VRRP Cluster | Priority | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Auth Type | Adver Int | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Virtual IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Authentication Data |
+---------------------------------------------------------------+
4 | |
+---------------------------------------------------------------+
5.2 IP Field Descriptions
5.2.1 Source Address
The real IP address of the interface the packet is being sent from.
5.2.2 Destination Address
The VRRP IP multicast address assigned by the IANA. It is defined to
be:
224.0.0.(TBD IANA assignment)
This is a link local scope multicast address. Routers should not
forward a datagram with this destination address regardless of its
TTL.
draft-ietf-vrrp-spec-00.txt [Page 6]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
5.2.3 TTL
The TTL should be set to 255. A VRRP router receiving a packet with
the TTL not equal to 255 MUST discard the packet.
5.2.4 Protocol
The VRRP IP protocol number assigned by the IANA. It is defined to
be (TBD).
5.3 VRRP Field Descriptions
5.3.1 Version
The version field specifies the VRRP protocol version of this packet.
This document defines version 1.
5.3.2 VRRP Cluster
The VRRP Cluster field specifies the cluster this packet applies to.
Note: The interface may participate in more than one VRRP cluster
simultaneously, perhaps serving as master in one cluster, while
simultaneously serving as backup in other clusters.
5.3.3 Priority
The priority field specifies the currently configured VRRP priority
value for this interface and cluster. Higher values equal higher
priority. This field is an 8 bit unsigned field, giving 1 as the
minimum priority, and 255 as the maximum priority. The default
priority is 100 (decimal).
Priority value of zero (0) has a special meaning. It means that the
current master had decided to stop running VRRP. This is used to
cause other backup routers to quickly become master with out having
to timeout the current master.
In the event that two or more routers within a cluster have equal
priority, and that priority is the highest priority in the cluster,
initially the router with the higher real interface IP address
(interpreted as a 32 bit unsigned integer) will become master. Any
new router joining the cluster with the same priority will not become
master even if it has a higher IP address unless the current master
goes down.
draft-ietf-vrrp-spec-00.txt [Page 7]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
5.3.4 Type
The type field specifies the type of this VRRP packet. The only
packet type defined in this version of the protocol is:
1 ADVERTISEMENT
All other values are currently unknown, and if a packet is received
with a value not listed, it should be discarded.
5.3.5 Authentication Type
The authentication type field identifies the authentication method
being utilized. The current supported authentications are listed
below:
0 - No authentication
1 - Simple text authentication
2 - IP Security Option Authentication
For simple text authentication any VRRP packet with an authentication
string that does not match its configured authentication string
should be discarded.
The authentication type field is an 8 bit number and must be one of
the above listed values.
5.3.5.1 IP Security Option Authentication
When authentication is performed by using the IP Authentication
Header as specified in [AUTH], the Authentication type should be set
to "2". If packet is received with the Authentication type set to
"2" indicating IP security option authentication and no
authentication header is present in the packet, the packet should be
discarded.
5.3.6 Advertisement Interval (Adver Int)
This field is the time interval for Master to Send ADVERTISEMENTS.
Default is 1 second. This field is used for troubleshooting
misconfigured routers.
5.3.7 Checksum
The checksum field is used to detect data corruption in the VRRP
message.
The checksum is the 16-bit one's complement of the one's complement
draft-ietf-vrrp-spec-00.txt [Page 8]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
sum of the entire VRRP message starting with the version field. For
computing the checksum, the checksum field is set to zero.
5.3.8 Virtual IP address
The virtual IP address field specifies the Virtual IP (VIP) address
associated with the particular cluster. This field is used for
troubleshooting misconfigured routers.
The VIP should be an IP address assigned from the subnet that the
interface is attached.
5.3.9 Authentication Data
The authentication string is currently utilized for simple text
authentication, similar to the simple text authentication found in
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 with an authentication string
that does not match its configured authentication string should be
discarded. The authentication string is unique on a per cluster
basis.
6. Protocol State Machine
6.1 Parameters
Cluster_ID Cluster identifier. Configured item.
Priority Priority value for this cluster. Configured
item. Default is 100 (decimal).
Virtual_IP Virtual IP Address for this cluster.
Configured item.
Advertisement_Interval Time interval for Master to Send
ADVERTISEMENTS. Default is 1 second.
Skew_Time Calculated time to skew
Master_Down_Interval. Defined to be:
( (256 - Priority) / 256 )
draft-ietf-vrrp-spec-00.txt [Page 9]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
Master_Down_Interval Time interval for Backup to declare Master
down. Defined to be:
(3 * Advertisement_Interval) + Skew_time
seconds.
6.2 Timers
Master_Down_Timer Timer which fires when Master has not been
heard for Master_Down_Interval.
Adver_Timer Timer which fires when time to send next
ADVERTISEMENT based on
Advertisement_Interval.
6.3 State Transition Diagram
+---------------+
| |<-------------+
+--------->| Initialize | |
| | |----------+ |
| +---------------+ | |
| | |
| V |
+---------------+ +---------------+
| |---------------------->| |
| Master | | Backup |
| |<----------------------| |
+---------------+ +---------------+
6.4 State Descriptions
In the below state descriptions, the state names will be identified
as follows {state-name}, and the packets will be identified by
utilizing all upper case characters.
6.4.1 Initialize
{Initialize} is the initial state an interface takes when VRRP is
enabled or disabled. The basic function of the state is to wait for
a startup event. When that is received it:
- Set the Master_Down_Timer to Master_Down_Interval
draft-ietf-vrrp-spec-00.txt [Page 10]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
- Set state to {Backup} state.
6.4.2 Backup
The main purpose of {Backup} state is for an interface to wait for
the current master to stop sending ADVERTISEMENT packets.
While in this state, an interface should do the following:
- Should not respond to ARP request for the interface VIP router
address
- Should discard packets with destination link layer MAC address
equal to virtual router MAC.
- Should discard packets addressed to the interface VIP address.
- If Master_Down_Timer fires, Send ADVERTISEMENT, set Adver_Timer
to Advertisement_Interval, and set state to {Master} state
- If ADVERTISEMENT received,
If Priority of the received ADVERTISEMENT is Zero, then set
Mater_Down_Timer to Skew_Time.
If Priority of the received ADVERTISEMENT is greater than
this interfaces Priority, then reset Master_Down_Timer.
If Priority of the received ADVERTISEMENT is equal to this
interfaces Priority, then reset Master_Down_Timer.
If Priority of the received ADVERTISEMENT is lower than this
interfaces Priority, then discard ADVERTISEMENT.
6.4.3 Master
In {Master} state an interface is functioning as the actual physical
router for the virtual router IP and MAC address.
While in this state, an interface should do the following:
- Accept and forward traffic for the virtual router MAC address.
- Respond to ARP requests for the VIP address with the virtual router
MAC address.
- Respond to packets addressed to the VIP address.
draft-ietf-vrrp-spec-00.txt [Page 11]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
- If Adver_Timer fires, send a ADVERTISEMENT and reset Adver_Timer.
- If ADVERTISEMENT received,
If Priority of the received ADVERTISEMENT is higher than this
interfaces Priority, then cancel Adver_Timer, Set
Master_Down_Timer, and set state to {Backup}.
If Priority of the received ADVERTISEMENT is equal to this
interfaces Priority, then:
If IP Address of sender of ADVERTISEMENT is higher than this
interfaces IP Address, then cancel Adver_Timer, Set
Master_Down_Timer, and set state to {Backup}.
If IP Address of sender of ADVERTISEMENT is lower than this
interfaces IP Address, discard ADVERTISEMENT.
If Priority of the received ADVERTISEMENT is lower than this
interfaces Priority, discard ADVERTISEMENT.
6.5 State Table
+---------------+---------------+---------------+---------------+
|Current State->| {Initialize} | {Backup} | {Master} |
| | | | |
| Event | | | |
| | | | | |
| V | | | |
+---------------+---------------+---------------+---------------+
| | Set Master_ | | |
| Startup | Down_Timer | | |
| | State = | | |
| | Backup | | |
+---------------+---------------+---------------+---------------+
| | | Cancel Master_| Cancel Adver_ |
| Shutdown | Ignore | Down_Timer | Timer |
| | Event | State = | Send ADVER w/ |
| | | Initialize | Priority=0 |
| | | | State = Init. |
+---------------+---------------+---------------+---------------+
| | | Send | |
| Master_Down_ | | ADVERTISEMENT| |
| Timer fires | | Set Adver_ | |
| | | Timer | |
| | | State = Master| |
draft-ietf-vrrp-spec-00.txt [Page 12]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
+---------------+---------------+---------------+---------------+
| Adver_Timer | | | Send ADVER. |
| fires | | | Reset Adver_ |
| | | | Timer |
+---------------+---------------+---------------+---------------+
| Receive VRRP | | Set Master_ | Send ADVER. |
| ADVERTISEMENT | | Down_Timer= | Reset Adver_ |
| with Priority | | Skew_Timer | Timer |
| equal Zero | | | |
+---------------+---------------+---------------+---------------+
| Receive VRRP | | | Cancel Adver_ |
| ADVERTISEMENT | | Reset | Timer |
| with Higher | | Master_Down_ | Set Master__ |
| Priority | | Timer | Down_Timer |
| | | | State = Backup|
+---------------+---------------+---------------+---------------+
| Receive VRRP | | | Cancel Adver_ |
| ADVERTISEMENT | | Reset | Timer |
| with Equal | | Master_Down_ | Set Master__ |
| Priority | | Timer | Down_Timer |
| and Higher IP | | | State = Backup|
| Address | | | |
+---------------+---------------+---------------+---------------+
| Receive VRRP | | | |
| ADVERTISEMENT | | Reset | Discard |
| with Equal | | Master_Down | Packet |
| Priority | | Timer | |
| and Lower IP | | | |
| Address | | | |
+---------------+---------------+---------------+---------------+
| Receive VRRP | | | |
| ADVERTISEMENT | | Discard | Discard |
| with Lower | | Packet | Packet |
| Priority | | | |
+---------------+---------------+---------------+---------------+
| Receive ARP | | | Send ARP |
| Request for | | Discard | Reply w/ |
| VIP address | | Packet | VMAC |
+---------------+---------------+---------------+---------------+
| Receive IP | | | Process as |
| packet w/ | | | Normal IP |
| Destination | | | Packet sent |
| = VIP | | | to Router |
+---------------+---------------+---------------+---------------+
| Receive IP | | | Process and |
| packet w/ | | | Forward as |
| Dest. MAC | | | Normal IP |
| = VMAC | | | Packet |
draft-ietf-vrrp-spec-00.txt [Page 13]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
+---------------+---------------+---------------+---------------+
| Unknown VRRP | | Discard | Discard |
| packet | | Packet | Packet |
+---------------+---------------+---------------+---------------+
7. Sending and Receiving VRRP Packets
7.1 Receiving VRRP Packets
The following rules must be performed when a VRRP packet is received:
- Verify TTL = 255.
- Verify that received packet length is greater or equal to VRRP
header length.
- Verify checksum in packet
- Verify version
- Verify Source address does not equal interface IP address
- Verify Cluster identifier valid on received interface
- Perform indicated authentication
- Verify VIP in packet is same as configured VIP for this cluster
- Verify Adver Interval in packet is same as configured VIP for
this cluster
If one of these checks fails, the receiver should discard the packet,
log the event and indicate via network management that an error
occurred.
7.2 Transmitting Packets
The following operations must be performed prior to transmitting a
VRRP packet.
- Fill in packet fields with appropriate interface and cluster
information
- Compute Checksum
- Set source MAC to Virtual MAC Address
- Send to VRRP IP Multicast Group
Note: VRRP packets are transmitted with the Virtual MAC address as
the source MAC to ensure that learning bridges correctly determine
the LAN segment the virtual MAC is attached to.
draft-ietf-vrrp-spec-00.txt [Page 14]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
7.3 Virtual MAC Address
The default virtual MAC address associated with the virtual IP
address is a IEEE 802 MAC Address of the following format:
00-00-5E-XX-XX-{cluster id} (in hex in internet standard bit-order)
The first three octets are the IANA's OUI. The next two octets (to
be assigned by the IANA) indicate the address address block assigned
to the VRRP protocol. {cluster id} in the last octet is the VRRP
cluster identifier. This mapping allows for up to 255 VRRP clusters
per interface.
Implementations may also allow Virtual MAC addresses to be configured
for each cluster.
8. Host Operation
8.1 Host ARP Requests
When a client sends a ARP request for the virtual IP address, the
appropriate master router should respond to the ARP request with the
above virtual MAC address for the appropriate cluster. This allows
the client to always use the same MAC address regardless of the
current master router. The request should be handled as a standard
ARP reply.
9. Operational Issues
9.1 ICMP Redirects
VRRP operation relies on the client host only using the Virtual IP
address and corresponding Virutal MAC. It is important that client
hosts do not learn the real IP address of VRRP routers on LAN
segment. Consequentially routers on the same LAN segment MUST NOT
send ICMP Redirects with the real IP address of any VRRP routers.
9.2 Proxy ARP
If Proxy ARP is being used on routers running VRRP, the VRRP routers
must advertise the Virtual MAC address in the Proxy ARP message.
Doing otherwise would cause them to learn the real IP address of the
VRRP routers.
draft-ietf-vrrp-spec-00.txt [Page 15]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
9.3 Network Management
It is important that network management tools (e.g., SNMP, Telnet,
etc.) always use the real IP addresses of VRRP routers. This is
necessary to insure that network management is aware of the real
status of the VRRP routers (e.g., detect that a router has failed so
that it can be repaired).
10. Operation over Token Ring
TBD
draft-ietf-vrrp-spec-00.txt [Page 16]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
11. References
[AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, Naval
Research Laboratory, August 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, BCP14, March 1997.
12. Security Considerations
The protocol design supports no authentication, simple text
authentication, and integrity/authentication/integrity using the IP
Security options.
13. Author's Addresses
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
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
David Whipple Phone: +1 206 703-3876
Microsoft Corporation EMail: dwhipple@microsoft.com
One Microsoft Way
Redmond, WA USA 98052-6399
Robert Hinden Phone: +1 408 990-2004
Ipsilon Networks, Inc. EMail: hinden@ipsilon.com
232 Java Drive
Sunnyvale, CA 94089
14. Acknowledgments
The authors would like to thank Glen Zorn, and Michael Lane, Clark
Bremer, Hal Peterson, Danny Mitzel, and Peter Hunt for their comments
and suggestions.
draft-ietf-vrrp-spec-00.txt [Page 17]
INTERNET-DRAFT Virtual Router Redundancy Protocol 22 June 1997
15. Changes from Previous Drafts
Changes from <draft-hinden-vrrp-00.txt>
- Changed default behavior to stay with current master when
priorities are equal. This behavior can be changed by configuring
explicit priorities.
- Changed Master state behavior to not send Advertisements when
receiving Advertisement with lower priorty. Change reduces worst
case election message overhead to "n", where "n" is number of
configured equal priority VRRP routers.
- Added Skew_Time parameter and changed receiving advertisement with
zero priority behavior to cause resulting advertisement sent to be
skewed by priority.
- Changed sending behavior to send VRRP packets with VMAC as source
MAC and added text describing why this is important for bridged
environments.
- Changed definition of VMAC to be in IANA assigned unicast MAC
block.
- Added Advertisement Interval to VRRP header.
- Added text regarding ICMP Redirects, Proxy ARP, and network
management issues.
- Various small text clarifications.
draft-ietf-vrrp-spec-00.txt [Page 18]
