home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_s_z
/
draft-whipple-vrrp-00.txt
< prev
next >
Wrap
Text File
|
1996-11-26
|
29KB
|
812 lines
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]
