RFC 2338
Virtual Router Redundancy Protocol
RFC 2338: Virtual Router Redundancy Protocol 🎀
Part 1 of 6 ✨
okay bestie, so this is RFC 2338, which is literally the spec for VRRP (Virtual Router Redundancy Protocol) 💖. It's on the Standards Track 👑 and was published in April 1998 🦋. It was written by a whole squad of people: S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, and A. Lindem. The affiliations listed are Ascend Communications, Inc., Microsoft, Inc., Nokia, Digital Equipment Corp., and IBM Corporation. It's part of the Network Working Group 🌸. The title block doesn't list anything it obsoletes or updates, so it's coming in fresh 🧚.
Status of this Memo 📜
ngl this part is kind of formal, but it's important 🫶. This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited 🌈.
Copyright Notice 💅
Copyright (C) The Internet Society (1998). All Rights Reserved. 💜
Abstract ✨
okay so the big idea 💖: this memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP is an election protocol that dynamically hands off responsibility for a virtual router to one of the VRRP routers on a LAN 🎀. The VRRP router that controls the IP address(es) of a virtual router is called the Master, and it forwards packets sent to those addresses 👑. If the Master becomes unavailable, the election process gives you dynamic fail over of the forwarding job 🔥. This means any of the virtual router's IP addresses on the LAN can be the default first hop router for end-hosts 🦋. The big win is a higher availability default path without having to configure dynamic routing or router discovery protocols on every end-host 🍓.
Table of Contents 🌸
1. Introduction...............................................2
2. Required Features..........................................5
3. VRRP Overview..............................................6
4. Sample Configurations......................................8
5. Protocol...................................................9
5.1 VRRP Packet Format....................................10
5.2 IP Field Descriptions.................................10
5.3 VRRP Field Descriptions...............................11
6. Protocol State Machine....................................13
6.1 Parameters............................................13
6.2 Timers................................................15
6.3 State Transition Diagram..............................15
6.4 State Descriptions....................................15
7. Sending and Receiving VRRP Packets........................18
7.1 Receiving VRRP Packets................................18
7.2 Transmitting Packets..................................19
7.3 Virtual MAC Address...................................19
8. Operational Issues........................................20
8.1 ICMP Redirects........................................20
8.2 Host ARP Requests.....................................20
8.3 Proxy ARP.............................................20
9. Operation over FDDI and Token Ring........................21
9.1 Operation over FDDI...................................21
9.2 Operation over Token Ring.............................21
10. Security Considerations...................................23
10.1 No Authentication....................................23
10.2 Simple Text Password.................................23
10.3 IP Authentication Header.............................24
11. Acknowledgments...........................................24
12. References................................................24
13. Authors' Addresses........................................25
14. Full Copyright Statement..................................271. Introduction 🌈
okay so end-hosts have a bunch of ways to figure out their first hop router toward a given IP destination 🧚. They can run (or snoop on) a dynamic routing protocol like Routing Information Protocol [RIP] or OSPF version 2 [OSPF] 💅, run an ICMP router discovery client [DISC] 🎀, or just use a statically configured default route ✨.
running a dynamic routing protocol on every end-host might be totally infeasible 🙈 for a bunch of reasons: admin overhead, processing overhead, security issues, or just not having a protocol implementation for some platforms 💀. Neighbor or router discovery protocols can need every host on the network to actively take part 😭. That leads to big timer values, to cut down on protocol overhead when there are tons of hosts 🦋. The result is a real delay in spotting a lost (aka dead) neighbor, which can cause unacceptably long "black hole" periods 🖤.
the statically configured default route is super popular 💖. It keeps configuration and processing overhead low on the end-host and virtually every IP implementation supports it 👑. This is probably going to stick around as dynamic host configuration protocols [DHCP] get deployed, since those usually hand out an end-host IP address and a default gateway 🍓. BUT ngl this creates a single point of failure 😬. If the default router goes down, it's a catastrophic event, and every end-host that can't find any alternate path is isolated 💀.
VRRP is designed to get rid of that single point of failure in the static default routed environment 🛡️✨. It specifies an election protocol that dynamically hands off responsibility for a virtual router to one of the VRRP routers on a LAN 🎀. The VRRP router controlling the IP address(es) of a virtual router is the Master, and it forwards packets sent to those IP addresses 👑. The election process gives you dynamic fail-over of the forwarding responsibility if the Master becomes unavailable 🔥. Any of the virtual router's IP addresses on a LAN can then be used as the default first hop router by end-hosts 🦋. Again, the advantage of VRRP is a higher availability default path without needing to configure dynamic routing or router discovery protocols on every end-host 🌸.
VRRP does a similar job to a couple of proprietary protocols 👀. One is the Hot Standby Router Protocol (HSRP) [HSRP] from Cisco Systems, Inc., and the other is the IP Standby Protocol [IPSTB] from Digital Equipment Corporation, Inc. 💜
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] 📚. (these are the official BCP 14 key words, so they carry real weight 🫶.)
The IESG/IETF take no position on the validity or scope of any intellectual property rights or other rights that might be claimed to pertain to the implementation or use of the technology, or on whether any license under such rights might or might not be available 🧾. For more info, check the IETF IPR web page at http://www.ietf.org/ipr.html 🔗.
1.1 Scope 🎀
the rest of this document covers the features, design goals, and theory of operation of VRRP 🌈. It presents the message formats, protocol processing rules, and the state machine that guarantee convergence to a single Virtual Router Master ✨. Last but not least, it covers operational issues related to MAC address mapping, handling of ARP requests, generation of ICMP redirect messages, and security issues 🔐.
This protocol is intended for use with IPv4 routers only 🙅♀️. If it's decided that similar functionality is wanted in an IPv6 environment, a separate specification will be produced 🦋.
1.2 Definitions 📖
Here's the glossary, bestie 💅. The table is kept exactly as the original has it:
VRRP Router A router running the Virtual Router Redundancy
Protocol. It may participate in one or more
virtual routers.
Virtual Router An abstract object managed by VRRP that acts
as a default router for hosts on a shared LAN.
It consists of a Virtual Router Identifier and
a set of associated IP address(es) across a
common LAN. A VRRP Router may backup one or
more virtual routers.
IP Address Owner The VRRP router that has the virtual router's
IP address(es) as real interface address(es).
This is the router that, when up, will respond
to packets addressed to one of these IP
addresses for ICMP pings, TCP connections,
etc.
Primary IP Address An IP address selected from the set of real
interface addresses. One possible selection
algorithm is to always select the first
address. VRRP advertisements are always sent
using the primary IP address as the source of
the IP packet.
Virtual Router Master The VRRP router that is assuming the
responsibility of forwarding packets sent to
the IP address(es) associated with the virtual
router, and answering ARP requests for these
IP addresses. Note that if the IP address
owner is available, then it will always become
the Master.
Virtual Router Backup The set of VRRP routers available to assume
forwarding responsibility for a virtual router
should the current Master fail.2.0 Required Features 🏆
this section lists the features that were considered mandatory and that guided the design of VRRP 💖.
2.1 IP Address Backup 🛡️
backing up IP addresses is the main job of VRRP 👑. While it handles electing a Virtual Router Master and the extra stuff below, the protocol should strive to:
- Minimize the duration of black holes. 🕳️
- Minimize the steady state bandwidth overhead and processing complexity. 📉
- Function over a wide variety of multiaccess LAN technologies capable of supporting IP traffic. 🌐
- Provide for election of multiple virtual routers on a network for load balancing ⚖️
- Support of multiple logical IP subnets on a single LAN segment. 🧩
2.2 Preferred Path Indication 🌸
okay so the simple way to pick a Master out of a group of redundant routers is to treat them all as equals and crown whichever one wins first 👑. but bestie, that's not how real life works 😭. there's usually a distinct preference (or a whole range of them) among the redundant routers, based on stuff like access link cost or speed, router performance or reliability, or other policy considerations. the protocol should let you express that relative path preference in an intuitive way, and guarantee Master convergence to the most preferential router that's currently available 💅✨
2.3 Minimization of Unnecessary Service Disruptions 🦋
once Master election is done, any unnecessary transitions between Master and Backup routers can cause a service disruption 💀. so after election, the protocol should make sure that no state transition gets triggered by any Backup router of equal or lower preference, as long as the Master keeps functioning properly. it's giving stability 🫶
some environments may want to avoid the state transition that happens when a router shows up that's more preferential than the current Master. so it may be useful to support an override of the immediate convergence to the preferred path. not me being picky, but it's a whole vibe 🙈
2.4 Extensible Security 🔐
the virtual router functionality works across a wide range of internetworking environments, and each one might have its own security policies 🌈. the protocol should require minimal configuration and overhead in insecure operation, provide strong authentication when increased security is required, and allow new security mechanisms to be integrated without breaking backwards compatible operation. main character energy for future-proofing 👑
2.5 Efficient Operation over Extended LANs 🧚
sending IP packets on a multiaccess LAN means mapping an IP address to a MAC address, obviously 💅. using the virtual router MAC address in an extended LAN with learning bridges can seriously change the bandwidth overhead of packets headed to the virtual router 😭. if the virtual router MAC address is never used as the source address in a link level frame, then the station location never gets learned, so all packets sent to the virtual router end up flooded everywhere 💀. to make this efficient, the protocol should: 1) use the virtual router MAC as the source in a packet sent by the Master to trigger station learning; 2) trigger a message immediately after transitioning to Master to update the station learning; and 3) trigger periodic messages from the Master to maintain the station learning cache 🎀
3.0 VRRP Overview 🎀
VRRP specifies an election protocol to provide the virtual router function described earlier. all protocol messaging is done with IP multicast datagrams, so it can run over a variety of multiaccess LAN technologies that support IP multicast 🦋. each VRRP virtual router has a single well-known MAC address allocated to it. this document currently only details the mapping to networks using the IEEE 802 48-bit MAC address. the virtual router MAC address is used as the source in all periodic VRRP messages sent by the Master router, to enable bridge learning in an extended LAN 🧚
a virtual router is defined by its virtual router identifier (VRID) and a set of IP addresses. a VRRP router may associate a virtual router with its real addresses on an interface, and may also be configured with additional virtual router mappings and priority for virtual routers it is willing to back up. the mapping between VRID and addresses must be coordinated among all VRRP routers on a LAN 💜
however, there's no restriction against reusing a VRID with a different address mapping on different LANs. the scope of each virtual router is restricted to a single LAN 🌸
to minimize network traffic, only the Master for each virtual router sends periodic VRRP Advertisement messages. a Backup router will not attempt to pre-empt the Master unless it has higher priority. this eliminates service disruption unless a more preferred path becomes available. it's also possible to administratively prohibit all pre-emption attempts. the only exception is that a VRRP router will always become Master of any virtual router associated with addresses it owns. if the Master becomes unavailable, the highest priority Backup will transition to Master after a short delay, providing a controlled transition of the virtual router responsibility with minimal service interruption ✨
VRRP defines three types of authentication. they give you simple deployment in insecure environments, added protection against misconfiguration, and strong sender authentication in security conscious environments 🔐. analysis of the protection each mechanism provides, and its vulnerabilities, is deferred to Section 10.0 Security Considerations. in addition, new authentication types and data can be defined in the future without affecting the format of the fixed portion of the protocol packet, which preserves backward compatible operation 🫶
the VRRP design gives rapid transition from Backup to Master to minimize service interruption. it also includes optimizations that cut protocol complexity while guaranteeing controlled Master transition for typical operational scenarios 💅. these optimizations result in an election protocol with minimal runtime state requirements, minimal active protocol states, and a single message type and sender. the typical operational scenarios are defined to be two redundant routers and/or distinct path preferences among each router. a side effect when these assumptions are violated (i.e., more than two redundant paths, all with equal preference) is that duplicate packets may be forwarded for a brief period during Master election 💀. however, the typical scenario assumptions are likely to cover the vast majority of deployments, loss of the Master router is infrequent, and the expected duration of Master election convergence is quite small ( << 1 second ). so the VRRP optimizations are significant simplifications in the protocol design, while incurring an insignificant probability of brief network degradation 👑
4. Sample Configurations 🍓
4.1 Sample Configuration 1 🧁
the following figure shows a simple network with two VRRP routers implementing one virtual router. note that this example is there to help you understand the protocol, but it's not expected to happen in actual practice 🙈
+-----+ +-----+
| MR1 | | BR1 |
| | | |
| | | |
VRID=1 +-----+ +-----+
IP A ---------->* *<--------- IP B
| |
| |
| |
------------------+------------+-----+--------+--------+--------+--
^ ^ ^ ^
| | | |
(IP A) (IP A) (IP A) (IP A)
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+ Legend:
---+---+---+-- = Ethernet, Token Ring, or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IP Address
(IP) = default router for hoststhe above configuration shows a very simple VRRP scenario. the end-hosts install a default route to the IP address of virtual router #1 (IP A), and both routers run VRRP. the router on the left becomes the Master for virtual router #1 (VRID=1), and the router on the right is the Backup for virtual router #1. if the router on the left fails, the other router will take over virtual router #1 and its IP addresses, and provide uninterrupted service for the hosts 🦋
note that in this example, IP B is not backed up by the router on the left. IP B is only used by the router on the right as its interface address. to back up IP B, a second virtual router would have to be configured. this is shown in the next section 💖
4.2 Sample Configuration 2 🌈
the following figure shows a configuration with two virtual routers, with the hosts splitting their traffic between them. this example is expected to be very common in actual practice 🔥
+-----+ +-----+
| MR1 | | MR2 |
| & | | & |
| BR2 | | BR1 |
VRID=1 +-----+ +-----+ VRID=2
IP A ---------->* *<---------- IP B
| |
| |
| |
------------------+------------+-----+--------+--------+--------+--
^ ^ ^ ^
| | | |
(IP A) (IP A) (IP B) (IP B)
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+ Legend:
---+---+---+-- = Ethernet, Token Ring, or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IP Address
(IP) = default router for hostsin the above configuration, half of the hosts install a default route to virtual router #1's IP address (IP A), and the other half install a default route to virtual router #2's IP address (IP B). this load balances the outgoing traffic while also providing full redundancy 💅
5.0 Protocol 👑
the purpose of the VRRP packet is to communicate to all VRRP routers the priority and the state of the Master router associated with the Virtual Router ID 🌈
VRRP packets are sent encapsulated in IP packets. they are sent to the IPv4 multicast address assigned to VRRP ✨
5.1 VRRP Packet Format 📦✨
okay so this section is where we get the exact layout of a VRRP packet and the bits of the IP header that matter for it. bestie, this is the blueprint, so let's look at it 🧐
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority | Count IP Addrs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Adver Int | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.2 IP Field Descriptions 🌐
5.2.1 Source Address
this one's simple: it's the primary IP address of the interface the packet is sent from 💖
5.2.2 Destination Address
the IP multicast address IANA assigned to VRRP is:
224.0.0.18heads up, this is a link local scope multicast address 👀 so Routers MUST NOT forward a datagram with this destination address, no matter what its TTL is. not me forwarding it anyway 💀
5.2.3 TTL
the TTL MUST be set to 255 🔒 and if a VRRP router gets a packet where the TTL is not equal to 255, it MUST discard that packet. no exceptions, periodt 💅
5.2.4 Protocol
the IP protocol number IANA assigned to VRRP is 112 (decimal) 🦋
5.3 VRRP Field Descriptions 🎀
5.3.1 Version
the version field tells you which VRRP protocol version the packet is using. this document defines version 2 ✨
5.3.2 Type
the type field tells you what kind of VRRP packet this is. the only packet type defined in this version is:
1 ADVERTISEMENTa packet with an unknown type MUST be discarded 🗑️
5.3.3 Virtual Rtr ID (VRID)
the Virtual Router Identifier (VRID) field says which virtual router this packet is reporting status for 🌸
5.3.4 Priority
the priority field is the sending VRRP router's priority for the virtual router. higher values mean higher priority 👑 this field is an 8 bit unsigned integer.
the priority value for the VRRP router that owns the IP address(es) tied to the virtual router MUST be 255 (decimal) 👑👑 the main character of the whole setup.
VRRP routers backing up a virtual router MUST use priority values between 1-254 (decimal). the default priority for those backup routers is 100 (decimal) 🧚
the priority value zero (0) is special 🚨 it means the current Master has stopped participating in VRRP. backup routers see that and quickly switch to Master, so they don't have to wait for the current Master to time out 🏃♀️💨
5.3.5 Count IP Addrs
this is the number of IP addresses in this VRRP advertisement 🔢
5.3.6 Authentication Type
the authentication type field says which authentication method is being used. it's unique on a per interface basis, and it's an 8 bit unsigned integer. a packet with an unknown authentication type, or one that doesn't match your locally configured method, MUST be discarded 🚫
the authentication methods currently defined are:
0 - No Authentication
1 - Simple Text Password
2 - IP Authentication Header5.3.6.1 No Authentication
this means the VRRP exchanges aren't authenticated at all 🫥 the Authentication Data field should be set to zero when sending, and ignored when receiving.
5.3.6.2 Simple Text Password
this means the VRRP exchanges are authenticated with a clear text password 📝 when sending, the Authentication Data field should be set to the locally configured password. there is no default password. the receiver MUST check that the Authentication Data in the packet matches its configured authentication string, and packets that don't match MUST be discarded.
⚠️ babe, simple text passwords come with security implications. one should see the Security Consideration section of this document, seriously 🙈
5.3.6.3 IP Authentication Header
this means the VRRP exchanges are authenticated using the mechanisms defined by the IP Authentication Header [AUTH], using "The Use of HMAC-MD5-96 within ESP and AH" [HMAC] 🔐 keys can be configured manually or handed out through a key distribution protocol.
if a packet comes in that fails the authentication check, either because the authentication header is missing or the message digest is wrong, then the packet MUST be discarded. the Authentication Data field should be set to zero when sending, and ignored when receiving.
5.3.7 Advertisement Interval (Adver Int)
this is the time interval, in seconds, between ADVERTISEMENTS ⏱️ the default is 1 second. it's mainly there to help troubleshoot misconfigured routers 🔍
5.3.8 Checksum
the checksum field catches data corruption in the VRRP message 🧼
the checksum is the 16-bit one's complement of the one's complement sum of the entire VRRP message, starting from the version field. when you're computing it, the checksum field is set to zero first 🧮
5.3.9 IP Address(es)
these are one or more IP addresses associated with the virtual router 🏠 how many there are gets specified in the "Count IP Addrs" field. these fields are for troubleshooting misconfigured routers too 🛠️
5.3.10 Authentication Data
the authentication string is only used for simple text authentication right now 🗝️ it's similar to the simple text authentication found in the Open Shortest Path First routing protocol [OSPF]. it's up to 8 characters of plain text. if your configured string is shorter than 8 bytes, the remaining space MUST be zero-filled. any VRRP packet received with an authentication string that doesn't match the locally configured one MUST be discarded 🚮 the string is unique on a per interface basis.
there is no default value for this field 🙅♀️
6. Protocol State Machine 🧠👑
okay this is the brain of VRRP 🧠💜 it's where the router's behaviour gets decided.
6.1 Parameters 📋
6.1.1 Parameters per Interface
Authentication_Type Type of authentication being used. Values
are defined in section 5.3.6.
Authentication_Data Authentication data specific to the
Authentication_Type being used.6.1.2 Parameters per Virtual Router
VRID Virtual Router Identifier. Configured item
in the range 1-255 (decimal). There is no
default.
Priority Priority value to be used by this VRRP
router in Master election for this virtual
router. The value of 255 (decimal) is
reserved for the router that owns the IP
addresses associated with the virtual
router. The value of 0 (zero) is reserved
for Master router to indicate it is
releasing responsibility for the virtual
router. The range 1-254 (decimal) is
available for VRRP routers backing up the
virtual router. The default value is 100
(decimal).
IP_Addresses One or more IP addresses associated with
this virtual router. Configured item. No
default.
Advertisement_Interval Time interval between ADVERTISEMENTS
(seconds). Default is 1 second.
Skew_Time Time to skew Master_Down_Interval in
seconds. Calculated as:
( (256 - Priority) / 256 )
Master_Down_Interval Time interval for Backup to declare Master
down (seconds). Calculated as:
(3 * Advertisement_Interval) + Skew_time
Preempt_Mode Controls whether a higher priority Backup
router preempts a lower priority Master.
Values are True to allow preemption and
False to not prohibit preemption. Default
is True.
Note: Exception is that the router that owns
the IP address(es) associated with the
virtual router always pre-empts independent
of the setting of this flag.6.2 Timers ⏰
Master_Down_Timer Timer that fires when ADVERTISEMENT has not
been heard for Master_Down_Interval.
Adver_Timer Timer that fires to trigger sending of
ADVERTISEMENT based on
Advertisement_Interval.6.3 State Transition Diagram 🦋🔁
okay picture the states bouncing between each other like a group chat 💬 this is the map of how a router moves between Initialize, Master, and Backup ✨
+---------------+
+--------->| |<-------------+
| | Initialize | |
| +------| |----------+ |
| | +---------------+ | |
| | | |
| V V |
+---------------+ +---------------+
| |---------------------->| |
| Master | | Backup |
| |<----------------------| |
+---------------+ +---------------+6.4. State Descriptions ✨
okay so this is where the state machine gets loud 📣. In these state descriptions, state names show up as {state-name}, and packets are written in ALL CAPS so you can spot them instantly 👀. Every VRRP router runs its own copy of the state machine for each virtual router election it's in, so one router can be juggling a few at once 🧚
6.4.1. Initialize 🌱
The whole point of this state is to sit and wait for a Startup event 🫶. When a Startup event arrives, the router checks who it is:
- If the Priority = 255 (i.e., the router owns the IP address(es) associated with the virtual router), then:
- Send an ADVERTISEMENT
- Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router
- Set
Adver_TimertoAdvertisement_Interval - Transition to
{Master}
- else:
- Set
Master_Down_TimertoMaster_Down_Interval - Transition to
{Backup}
- Set
endif
6.4.2. Backup 🛡️
The {Backup} state is basically the router's little watch shift 👀. Its job is to keep an eye on whether the Master Router is still alive and what it's up to 💅
While in this state, a VRRP router MUST do the following:
- MUST NOT respond to ARP requests for the IP address(es) associated with the virtual router. not me answering for the virtual router's IPs 🙈
- MUST discard packets with a destination link layer MAC address equal to the virtual router MAC address.
- MUST NOT accept packets addressed to the IP address(es) associated with the virtual router.
- If a Shutdown event is received, then:
- Cancel the
Master_Down_Timer - Transition to the
{Initialize}state
- Cancel the
endif- If the
Master_Down_Timerfires, then:- Send an ADVERTISEMENT
- Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router
- Set
Adver_TimertoAdvertisement_Interval - Transition to the
{Master}state
endif- If an ADVERTISEMENT is received, then:
- If the Priority in the ADVERTISEMENT is Zero, then:
- Set
Master_Down_TimertoSkew_Time
- Set
- else:
- If
Preempt_Modeis False, or if the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then:- Reset
Master_Down_TimertoMaster_Down_Interval
- Reset
- else:
- Discard the ADVERTISEMENT
endif
- If
endif
- If the Priority in the ADVERTISEMENT is Zero, then:
endif
6.4.3. Master 👑
This is the main character moment ✨. While in the {Master} state, the router is the forwarding router for the IP address(es) associated with the virtual router. Iconic behaviour 💖
While in this state, a VRRP router MUST do the following:
- MUST respond to ARP requests for the IP address(es) associated with the virtual router.
- MUST forward packets with a destination link layer MAC address equal to the virtual router MAC address.
- MUST NOT accept packets addressed to the IP address(es) associated with the virtual router if it is not the IP address owner.
- MUST accept packets addressed to the IP address(es) associated with the virtual router if it is the IP address owner.
- If a Shutdown event is received, then:
- Cancel the
Adver_Timer - Send an ADVERTISEMENT with Priority = 0
- Transition to the
{Initialize}state
- Cancel the
endif- If the
Adver_Timerfires, then:- Send an ADVERTISEMENT
- Reset the
Adver_TimertoAdvertisement_Interval
endif- If an ADVERTISEMENT is received, then:
- If the Priority in the ADVERTISEMENT is Zero, then:
- Send an ADVERTISEMENT
- Reset the
Adver_TimertoAdvertisement_Interval
- else:
- If the Priority in the ADVERTISEMENT is greater than the local Priority, or if the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IP Address of the sender is greater than the local primary IP Address, then:
- Cancel
Adver_Timer - Set
Master_Down_TimertoMaster_Down_Interval - Transition to the
{Backup}state
- Cancel
- else:
- Discard the ADVERTISEMENT
endif
- If the Priority in the ADVERTISEMENT is greater than the local Priority, or if the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IP Address of the sender is greater than the local primary IP Address, then:
endif
- If the Priority in the ADVERTISEMENT is Zero, then:
endif
7. Sending and Receiving VRRP Packets 📦
7.1. Receiving VRRP Packets 📥
Here's the bouncer checklist 💅. When a VRRP packet shows up, the receiver does the following:
- MUST verify that the IP TTL is 255.
- MUST verify the VRRP version.
- MUST verify that the received packet length is greater than or equal to the VRRP header.
- MUST verify the VRRP checksum.
- MUST perform authentication specified by Auth Type.
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. no cap, that's a lot of paperwork for one bad packet 😭
- MUST verify that the VRID is valid on the receiving interface.
If the above check fails, the receiver MUST discard the packet.
- MAY verify that the IP address(es) associated with the VRID are valid.
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, it continues 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. this is the glow-up checklist before anything leaves the router 💖
- Fill in the VRRP packet fields with the appropriate virtual router configuration state.
- Compute the VRRP checksum.
- 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 go out with the virtual router MAC address as the source MAC address 🦋. That's how learning bridges figure out which LAN segment the virtual router is actually attached to. so clever, honestly 🧠✨
7.3. Virtual Router MAC Address 🎀
The virtual router MAC address for a virtual router is an IEEE 802 MAC Address that looks like this:
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) are the address block assigned to the VRRP protocol. {VRID} is the VRRP Virtual Router Identifier. This mapping gives you up to 255 VRRP routers on a network 💜
8. Operational Issues 🧩
8.1. ICMP Redirects 🔀
ICMP Redirects may be used normally when VRRP is running between a group of routers. This lets VRRP work in environments where the topology is not symmetric, which is lowkey iconic 🌈
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 lets the client always use the same MAC address, no matter which router is currently the Master 💖
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. patience is a whole aesthetic 🫶
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 message. Doing otherwise could cause hosts to learn the real MAC address of the VRRP router. ngl that would be a total leak 😭🫣
9. Operation over FDDI and Token Ring 💍
9.1. Operation over FDDI 🌀
FDDI interfaces remove frames from the FDDI ring when those frames 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 an FDDI device, then other Masters' ADVERTISEMENTS will be removed from the ring during the Master convergence, and convergence will fail. bestie, that's a disaster arc 💀
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 stop a Master router from removing any ADVERTISEMENTS it did not originate 🦋✨
9.2 Operation over Token Ring
okay bestie, token ring is lowkey a whole mood for VRRP 💀 It's got a couple of quirks that make running it really tricky:
- To switch to a new master on a different bridge ring from the old master when you're using source route bridges, a mechanism is required to update cached source route information. 🧭
- There's no general multicast mechanism that works across old and new token ring adapters 😭 Newer adapters support group addresses, but token ring functional addresses are the only multicast option that's generally available. And since there aren't many of those, they can collide with other stuff using the same ones. 💥
Because of all that drama, the preferred mode over token ring is to use a token ring functional address for the VRID virtual MAC address 🎀 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). Unlike multicast addresses, there's only one unique functional address per bit position, so it's very exclusive 👑 The functional 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. But since there are only 12 user-defined token ring functional addresses, other non-IP protocols might be using the same ones 🙈 Novell IPX [IPX] uses 03-00-00-10-00-00, so operation of VRRP over token ring avoids that one. In general, token ring VRRP users are responsible for sorting out any other user-defined functional address conflicts 💅
VRIDs get mapped directly to token ring functional addresses. To lower the odds of conflicts, allocation starts with the largest functional address 🦋 Most non-IP protocols use the first or first couple of user-defined functional addresses, so VRRP users are expected to pick VRIDs sequentially, starting with 1. ✨
The mapping table:
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-00Or more succinctly, octets 3 and 4 of the functional address are equal to (0x4000 >> (VRID - 1)) in non-canonical format. 🧚
Since a functional address can't be used as a MAC level source address, the real MAC address is used as the MAC source address in VRRP advertisements. This isn't a problem for bridges, since packets addressed to functional addresses get 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. This one's not optional, bestie! 🚨
Routers MAY also support unicast mode 💖 This takes advantage of newer token ring adapters that support non-promiscuous reception for multiple unicast MAC addresses, and it dodges both the multicast traffic and the usage conflicts that come with functional addresses. Unicast mode uses the same mapping of VRIDs to virtual MAC addresses as Ethernet, but there's one important difference: ARP request/reply packets contain the virtual MAC address as the source MAC address. Why? Some token ring driver implementations keep a cache of MAC address/source routing information that's separate from the ARP cache 🧠 So those implementations need 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 you should definitely think about 🥺 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 don't listen to gratuitous ARPs, those hosts won't update their ARP source-route information correctly when a switch-over happens. The only possible fix is to put all routers with the same VRID on the same source-route bridge segment, and then use techniques to stop that bridge segment from being a single point of failure. Those techniques are beyond the scope of this document. 🚧
For both the multicast and unicast modes of operation, VRRP advertisements sent to 224.0.0.18 should be encapsulated as described in [RFC1469]. 📦
10. Security Considerations
Okay, this section is serious, so read it carefully! 🚨🔐
VRRP is designed for a range of internetworking environments that may each employ different security policies. The protocol includes several authentication methods, ranging from no authentication, to simple clear text passwords, to 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. 🛡️
10.1 No Authentication
Using this authentication type means that VRRP protocol exchanges are not authenticated. This type of authentication SHOULD only be used in environments where there is minimal security risk and little chance for configuration errors (e.g., two VRRP routers on a LAN). 🙃
10.2 Simple Text Password
Using this authentication type means that VRRP protocol exchanges are authenticated by a simple clear text password. 🔑
This type of authentication is useful for protecting against accidental misconfiguration of routers on a LAN 🙌 It protects against routers inadvertently backing up another router. A new router must first be configured with the correct password before it can run VRRP with another router. But here's the tea: this type of authentication does not protect against hostile attacks, because a node snooping VRRP packets on the LAN can learn the password 👀 Simple Text Authentication combined with the TTL check makes it difficult for a VRRP packet sent from another LAN to disrupt VRRP operation, though.
This type of authentication is RECOMMENDED when there is minimal risk of nodes on a LAN actively disrupting VRRP operation. If you use this type of authentication, be aware that this clear text password is sent frequently, so it should not be the same as any security significant password. 🔐⚠️
10.3 IP Authentication Header
Using this authentication type means the VRRP protocol exchanges are authenticated using the mechanisms defined by the IP Authentication Header [AUTH], using "The Use of HMAC-MD5-96 within ESP and AH", [HMAC]. This provides strong protection against configuration errors, replay attacks, and packet corruption/modification. This is the big-brain option 🧠✨
This type of authentication is RECOMMENDED when there is limited control over the administration of nodes on a LAN. While it does protect the operation of VRRP, other kinds of attacks that can be used on shared media links (e.g., generation of bogus ARP replies) are independent of VRRP and are not protected. 🦖 Know your threat model, bestie!
11. Acknowledgments
The authors would like to thank Glen Zorn, and Michael Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve Bellovin, and Thomas Narten for their comments and suggestions. 🫶💜
12. References
[802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std
802.1D, 1993 edition.
[AUTH] Kent, S., and R. Atkinson, "IP Authentication Header",
Work in Progress.
[DISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[HMAC] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", Work in Progress.
[HSRP] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby
Router Protocol (HSRP)", RFC 2281, March 1998.
[IPSTB] Higginson, P., M. Shand, "Development of Router Clusters to
Provide Fast Failover in IP Networks", Digital Technical
Journal, Volume 9 Number 3, Winter 1997.
[IPX] Novell Incorporated., "IPX Router Specification", Version
1.10, October 1992.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RIP] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1469] Pusateri, T., "IP over Token Ring LANs", RFC 1469, June
1993.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TKARCH] IBM Token-Ring Network, Architecture Reference, Publication
SC30-3374-02, Third Edition, (September, 1989).13. Authors' 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
USA
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
USA
David Whipple Phone: +1 206 703-3876
Microsoft Corporation EMail: dwhipple@microsoft.com
One Microsoft Way
Redmond, WA USA 98052-6399
USA
Robert Hinden Phone: +1 408 990-2004
Nokia EMail: hinden@iprg.nokia.com
232 Java Drive
Sunnyvale, CA 94089
USA
Danny Mitzel Phone: +1 408 990-2037
Nokia EMail: mitzel@iprg.nokia.com
232 Java Drive
Sunnyvale, CA 94089
USA
Peter Hunt Phone: +1 408 990-2093
Nokia EMail: hunt@iprg.nokia.com
232 Java Drive
Sunnyvale, CA 94089
USA
P. Higginson Phone: +44 118 920 6293
Digital Equipment Corp. EMail: higginson@mail.dec.com
Digital Park
Imperial Way
Reading
Berkshire
RG2 0TE
UK
M. Shand Phone: +44 118 920 4424
Digital Equipment Corp. EMail: shand@mail.dec.com
Digital Park
Imperial Way
Reading
Berkshire
RG2 0TE
UK
Acee Lindem Phone: 1-919-254-1805
IBM Corporation E-Mail: acee@raleigh.ibm.com
P.O. Box 12195
Research Triangle Park, NC 27709
USA14. Full Copyright Statement ✨
Copyright (C) The Internet Society (1998). All Rights Reserved. 🎀
okay so this is the legal bit, and it's actually lowkey important 💅 The Internet Society owns the copyright, and you're allowed to copy this doc and pass it around to your friends 🫶 You can also make derivative works that comment on it, explain it, or help people actually implement it, and you can publish and distribute those too, in whole or in part, with no real restrictions 🦋 The one condition is that the copyright notice and this paragraph have to stay on every copy and every derivative work 💖
BUT (and this is the not-me moment 💀), the document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are if you're developing Internet standards, in which case the procedures for copyrights in the Internet Standards process have to be followed, or if you're translating it into a language other than English 🌍
The permissions above are perpetual, which means they're forever 🧚 The Internet Society and its successors or assigns will never take them back ✨
Last but not least, this document and everything in it is provided "AS IS", 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 🌸 Translation: they're not promising it'll work perfectly for you, so don't blame them if it doesn't 😭
📦 where this page comes from
- ietf: rfc2338 1998-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms