S. Knight Internet-Draft Ascend Communications, Inc. D. Weaver Ascend Communications, Inc. D. Whipple Microsoft, Inc. November 1996 Virtual Router Redundancy Protocol draft-whipple-vrrp-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 draft originaly published November 1996. It expires April, 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 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. In addition, priorities may be set to control the order in which particular routers become master for the cluster. Overall, this protocol adds to the options for providing fault redundancy for router networks. Knight/Whipple/Weaver Expires April 1997 [Page 1] Internet-Draft draft-whipple-vrrp-00.txt April 1997 TABLE OF CONTENTS 1 Introduction 3 2 Scope 3 2.1 Terminology 4 3 Definitions 4 4 Sample Configurations 5 4.1 Sample Configuration 1 5 4.2 Sample Configuration 2 6 5 Protocol 7 5.1 Packet Format 7 5.2 Field Descriptions 7 5.2.1 Version 7 5.2.2 VRRP Cluster 7 5.2.3 Priority 8 5.2.4 Type 8 5.2.5 Real MAC Address 8 5.2.6 Virtual IP Address 8 5.2.7 Authentication Type 8 5.2.8 Authentication String 9 6 State Descriptions 9 6.1 State Transition Diagram 9 6.2 State Descriptions 9 6.2.1 Startup 10 6.2.2 Takeover 10 6.2.3 Master 11 6.2.4 Backup 11 6.3 State Table 12 7 Sending and Receiving VRRP Packets 12 7.1 VRRP Packet MAC Address 12 7.2 VRRP Packet ETHERTYPE 13 8 Client Interaction 13 8.1 Client ARP Requests 13 9 References 13 10 Security Considerations 14 11 Authors' Addresses 14 12 Acknowledgements 14 Knight/Whipple/Weaver Expires April 1997 [Page 2] Internet-Draft draft-whipple-vrrp-00.txt April 1997 1 Introduction The reason for the development of VRRP is to create a standard protocol, with multivendor 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. 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. 2 Scope This memo describes the Master Router Redundancy Protocol. This protocol is intended for IPv4 only, with extensions for IPv6 to be added at a later time. Within the scope of this memo 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 Knight/Whipple/Weaver Expires April 1997 [Page 3] Internet-Draft draft-whipple-vrrp-00.txt April 1997 2.1 Terminology The following language conventions are used in the items of specification in this document: "Must," "Shall," or "Mandatory"--the item is an absolute requirement of the specification. "Should" or "Recommended"--the item should generally be followed for all but exceptional circumstances. "May" or "Optional"--the item is truly optional and may be followed or ignored according to the needs of the implementor. 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. Knight/Whipple/Weaver Expires April 1997 [Page 4] Internet-Draft draft-whipple-vrrp-00.txt April 1997 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 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) Knight/Whipple/Weaver Expires April 1997 [Page 5] Internet-Draft draft-whipple-vrrp-00.txt April 1997 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) Knight/Whipple/Weaver Expires April 1997 [Page 6] Internet-Draft draft-whipple-vrrp-00.txt April 1997 5 Protocol 5.1 Packet Format The following shows the layout of the VRRP packet. Each VRRP packet MUST have the same format. The purpose of the VRRP packet is to communicate to all other VRRP routers, both the priority and the state of the associated interface. 31 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Version | VRRP Cluster | Priority | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Real MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Address | ZERO PADDING | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Virtual IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Auth Type | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Authentication String | +---------------------------------------------------------------+ 6 | | +---------------------------------------------------------------+ 5.2 Field Descriptions 5.2.1 Version The version field specifies the version of this VRRP protocol packet. The initial version described in this paper is version 1. Implementations MAY assume that the layout of the fields in the version 1 of the protocol packet will remain constant through version 7, and that version numbers up to 7 will only add additional fields to the end of the packet. Current implementations SHOULD ignore any packets with a version number of 8 or higher, which may allow the entire packet format to be changed, if necessary, at some future date without invalidating current implementations. 5.2.2 VRRP Cluster The VRRP Cluster field specifies the cluster for which this interface is in the reported state, with the reported priority. Note: The interface may be in more than one VRRP cluster simultaneously, perhaps serving as master in one cluster, while simultaneously serving as backup in other clusters. Knight/Whipple/Weaver Expires April 1997 [Page 7] Internet-Draft draft-whipple-vrrp-00.txt April 1997 5.2.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 0 as the minimum priority, and 255 as the maximum priority. The default priority is 100. In the event that two or more routers within a cluster have equal priority, and that priority is the highest priority in the cluster, the router with the higher real MAC address (interpreted as a 48 bit unsigned integer) will become master. 5.2.4 Type The type field specifies the type of this VRRP packet. This should directly reflect the current state of the sending interface (other than the RESIGN packet). The available packet types are listed below: 0 (00000000): RESIGN 1 (00000001): MASTER 2 (00000010): TAKEOVER 3 (00000011): BACKUP All other values are currently unknown, and if a packet is received with a value not listed, it should be discarded. 5.2.5 Real MAC Address The real MAC address field specifies the real IEEE MAC address of the participating interface in a VRRP cluster. The extra two bytes in the two words that hold the address are unused, and must be zero-filled. 5.2.6 Virtual IP address The virtual IP address field specifies the virtual IP address associated with the particular cluster. This field is particularly useful for troubleshooting misconfigured routers. 5.2.7 Authentication Type The authentication type field identifies the authentication method being utilized. The current supported authentication's are listed below: 0 - No authentication 1 - Simple text authentication Knight/Whipple/Weaver Expires April 1997 [Page 8] Internet-Draft draft-whipple-vrrp-00.txt April 1997 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.2.8 Authentication String 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. Note: A real authentication mechanism will be implemented in a future version of the protocol. 6 State Descriptions 6.1 State Transition Diagram +-------------+ | | +---------->| Master |---------+ | | | | | +-------------+ | | | | V +-------------+ +-------------+ | +-------------------->+ | | Takeover | | Backup | | +<--------------------+ | +-------------+ +-------------+ ^ | | +-------------+ | | | Startup | | | +-------------+ 6.2 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. Knight/Whipple/Weaver Expires April 1997 [Page 9] Internet-Draft draft-whipple-vrrp-00.txt April 1997 6.2.1 Startup {Startup} is the initial state an interface takes after booting, or if VRRP is disabled upon booting, when VRRP is enabled. Upon entering {startup} state, transition immediately to {takeover} state. 6.2.2 Takeover In a {takeover} state an interface is advertising via a MAC layer multicast address that it's prepared to take over as master for a specific cluster. This intermediate state is intended to prevent a router from becoming master too quickly as a result of lost VRRP packets during congestion. This essentially gives the current master (or any other router with higher priority) a chance to advertise itself as a better choice. Note: This doesn't eliminate the possibility of transitioning inappropriately, enough packets could get lost, but this makes this less likely to occur. While in this state, an interface should do the following: Send a TAKEOVER packet every X seconds, where X is configurable and defaults to 1. Upon receiving any MASTER or TAKEOVER packet with a higher priority than itself, transition to a {backup} state. Upon receiving a RESIGN packet, transition to a {master} state. DISCUSSION: This assumes that the resignation is the current master telling us to take over because this interface has a higher priority. This would be a common case during startup, and the lower-priority router gets up before the higher-priority router. If Y seconds pass without receiving a MASTER or TAKEOVER packet with a higher priority than itself, transition to {master} state. Y should be configurable and default to 1. Knight/Whipple/Weaver Expires April 1997 [Page 10] Internet-Draft draft-whipple-vrrp-00.txt April 1997 6.2.3 Master In a {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. Send a MASTER packet every X seconds, where X is configurable and defaults to 1. Upon receiving any MASTER or TAKEOVER packet with a higher priority than itself, send a RESIGN packet, transition to a {backup} state. Upon receiving a RESIGN packet, send a MASTER packet, stay in {master} state. 6.2.4 Backup In a {backup} state, an interface should simply wait for the current master to stop sending MASTER packets. While in this state, an interface should do the following: Send a BACKUP packet every X seconds, where X is configurable and defaults to 3. Upon receiving a RESIGN packet, transition to {takeover} state. DISCUSSION: This may be because the current master is being reconfigured to give up duties in an orderly fashion. So let's tell the world that this interface can take over if it's necessary. If another interface/router has a higher priority, they'll takeover instead. If Y seconds pass without receiving a MASTER or TAKEOVER packet with a higher priority than itself, transition to {takeover}. The default value for Y is 2. Knight/Whipple/Weaver Expires April 1997 [Page 11] Internet-Draft draft-whipple-vrrp-00.txt April 1997 6.3 State Table +---------------+---------------+---------------+---------------+ |Current State->| In {master} | In {takeover} | In {backup} | | | | | | |Packet | | | | |Received | | | | | | V | | | | +---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+ |MASTER with |Send RESIGN |Transition to |Update only, | |higher priority|Transition to |{backup} |No state | | |{backup} | |change | +---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+ |MASTER with |Send MASTER |Send TAKEOVER |Update only, | |lower priority | |Continue |No state | | | |Countdown timer|change | | | |to {master} | | +---------------+---------------+---------------+---------------+ |RESIGN |Send MASTER |Transition to |Update only, | | | |{master} |No state | | | | |change | +---------------+---------------+---------------+---------------+ |TAKEOVER with |Send RESIGN |Transition to |Update only, | |higher priority|Transition to |{backup} |No state | | |{backup} | |change | +---------------+---------------+---------------+---------------+ |TAKEOVER with |Send MASTER |Send TAKEOVER |Update only, | |lower priority | | |No state | | | | |change | +---------------+---------------+---------------+---------------+ |BACKUP |Update only, |Update only, |Update only, | | |No state |No state |No state | | |change |change |change | +---------------+---------------+---------------+---------------+ |UNKNOWN VRRP |Discard PKT. |Discard PKT. |Discard PKT. | |packet |No state |No state |No state | | |change |change |change | +---------------+---------------+---------------+---------------+ 7 Sending and Receiving VRRP Packets 7.1 VRRP Packet MAC Address All VRRP packets should be exchanged using the following IEEE 802 MAC Address: 03:xx:xx:xx:xx:{cluster id} (to be filled in when assigned) Currently using - 03:C0:80:0A:6F:{cluster id}(in hex) Knight/Whipple/Weaver Expires April 1997 [Page 12] Internet-Draft draft-whipple-vrrp-00.txt April 1997 The initial 03: of the address sets the local flag (the 02: bit), and the MCAST flag (the 01: bit) in the IEEE MAC address. This MAC address has been assigned for use as the VRRP packet exchange address by the IANA (Internet Assigned Numbering Authority), or the IEEE. 7.2 VRRP Packet TYPE All VRRP Packets should be sent with the following ETHERTYPE value in the 802.1 frame header. 0x8045?? (Again to be assigned) This VRRP ETHERTYPE value has been assigned by Xerox corporation for exclusive type determination. 8 Client Interaction 8.1 Client 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 reserved MAC address for the appropriate group. 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, utilizing ETHERTYPE 0x0806. 9 References [1] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981. [2] IEEE, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985. [3] IEEE, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985. [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [5] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994. Knight/Whipple/Weaver Expires April 1997 [Page 13] Internet-Draft draft-whipple-vrrp-00.txt April 1997 10 Security Considerations The current protocol design supports no authentication, and simple text authentication. It is designed to allow future (stronger) authentication methods to be incorporated. A enhanced authentication system should be designed for the next revision of the protocol. 11 Author's Address Steven Knight Ascend Communications High Performance Network Division 10250 Valley View Road, Suite 113 Eden Prairie, MN USA 55344 Phone: (612) 943-8990 EMail: Steven.Knight@ascend.com Douglas Weaver Ascend Communications High Performance Network Division 10250 Valley View Road, Suite 113 Eden Prairie, MN USA 55344 Phone: (612) 943-8990 EMail: Doug.Weaver@ascend.com David Whipple Microsoft Corporation One Microsoft Way Redmond, WA USA 98052-6399 Phone: (206) 703-3876 EMail: dwhipple@microsoft.com VRRP Mailing List: vrrp@drcoffsite.com To subscribe to this mailing list send a message to listserv@drcoffsite.com with "subscribe vrrp Your Name" in the body of the message. 12 Acknowledgements The authors would like to thank Glen Zorn (Microsoft), and Michael Lane (Microsoft), Clark Bremer (Ascend), Hal Peterson (Ascend). Knight/Whipple/Weaver Expires April 1997 [Page 14]