Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Virtual Router Redundancy Protocol
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{Short description|Inter-router protocol that automatically assigns routers to hosts}} {{Distinguish|Vehicular Reactive Routing protocol}} The '''Virtual Router Redundancy Protocol''' ('''VRRP''') is a computer [[networking protocol]] that provides for automatic assignment of available [[Internet Protocol]] (IP) routers to participating [[Host (network)|hosts]]. This increases the availability and reliability of [[routing]] paths via automatic [[default gateway]] selections on an IP [[subnetwork]]. The protocol achieves this by the creation of virtual routers, which are an abstract representation of multiple routers, i.e. primary/active and secondary/Standby [[router (computing)|router]]s, acting as a group. The virtual router is assigned to act as a default gateway of participating hosts, instead of a physical router. If the physical router that is routing packets on behalf of the virtual router fails, another physical router is selected to automatically replace it. The physical router that is forwarding [[Network_packet|packets]] at any given time is called the primary/active router. VRRP provides information on the state of a router, not the routes processed and exchanged by that router. Each VRRP instance is limited, in scope, to a single subnet. It does not advertise IP routes beyond that subnet or affect the routing table in any way. VRRP can be used in [[Ethernet]], [[Multiprotocol Label Switching|MPLS]] and [[Token Ring]] networks with [[IPv4|Internet Protocol Version 4]] (IPv4), as well as [[IPv6]]. ==Implementation== A virtual router must use {{MACaddr|00-00-5E-00-01-XX}} as its [[media access control]] (MAC) address. The last byte of the address (XX) is the virtual router identifier (VRID), which is different for each virtual router in the network. This address is used by only one physical router at a time, and it will reply with this [[MAC address]] when an [[Address Resolution Protocol|ARP]] request is sent for the virtual router's IP address. Physical routers within the virtual router must communicate within themselves using packets with [[Multicast address|multicast]] [[Internet Protocol|IP]] address {{IPaddr|224.0.0.18}} and [[List of IP protocol numbers|IP protocol number]] 112{{Ref RFC|5798}} for IPv4, or {{IPaddr|ff02::12}} and IP protocol number 112 for IPv6{{Ref RFC|5798}}. Routers backing up a virtual router have a priority between 1 and 254, and the router with the highest priority will become the primary/active. The default priority is 100; for the MAC address owner, the priority is always 255. ==Elections of primary/active routers== A failure to receive a multicast packet from the primary/active router for a period longer than three times the advertisement timer causes the secondary/standby routers to assume that the primary/active router is dead. The virtual router then transitions into an unsteady state and an election process is initiated to select the next primary/active router from the secondary/standby routers. This is fulfilled through the use of multicast packets. Secondary/standby router(s) are only supposed to send multicast packets during an election process. One exception to this rule is when a physical router is configured with a higher priority than the current primary/active, which means that on connection to the network it will pre-empt the primary/active status. This allows a system administrator to force a physical router to the primary/active state immediately after [[booting]], for example when that particular router is more powerful than others within the virtual router. The secondary/standby router with the highest priority becomes the primary/active router by raising its priority above that of the current primary/active. It will then take responsibility for routing packets sent to the virtual gateway's MAC address. In cases where secondary/standby routers all have the same priority, the secondary/standby router with the highest IP address becomes the primary/active router. All physical routers acting as a virtual router must be in the same [[local area network]] (LAN) segment. Communication within the virtual router takes place periodically. This period can be adjusted by changing advertisement interval timers. The shorter the advertisement interval, the shorter the [[Black_hole_(networking)|black hole]] period, though at the expense of more traffic in the network. Security is achieved by responding only to first [[Hop_(networking)|hop]] packets, though other mechanisms are provided to reinforce this, particularly against local attacks. The election process is made orderly through the use of [[Timing skew|skew time]], derived from a router's priority, and used to reduce the chance of the [[thundering herd problem]] occurring during the election. The skew time is given by the formula {{math|(256 β ''Priority'') / 256}} (expressed in milliseconds). Secondary/standby router utilization can be improved by load sharing.{{Ref RFC|5798|rsection=4.2}} ==History== Work on VRRP started in 1997 with a first draft published by the [[Internet Engineering Task Force]] (IETF). In 1998, the protocol was officially defined.{{Ref RFC|2338}} VRRP is an open standard, but [[Cisco]] claimed that their [[Hot Standby Router Protocol]], a similar but [[proprietary]] protocol with essentially the same facility, is patented and licensed.<ref>[https://web.archive.org/web/20100805130809/http://www.ietf.org/ietf-ftp/IPR/VRRP-CISCO IETF source]</ref> However, in 2001, in reply to a direct request, Robert Barr of Cisco replied that they will not assert any patent claims unless someone tried to assert a claim against Cisco.<ref name="barr2001">{{cite web |url=http://lists.graemef.net/pipermail/lvs-users/2001-November/028982.html |title=[VRRP & OpenSource] Cisco answer |date=2001-11-30 |access-date=2013-11-28 |author=Alexandre Cassen |publisher=LVS mailing list |quote=Robert Barr, from CISCO Systems: Cisco will not assert any patent claims against anyone for an implementation of IETF standard for VRRP unless a patent claim is asserted against Cisco, in which event Cisco reserves the right to assert patent claims defensively.}}</ref> [[IBM]] also claims covering patents and their statement is readable on the IETF webpage.<ref name="IBM-statement">{{cite web |url=http://ietf.org/ietf/IPR/ibm-rfc2338-rfc2787.txt |title=IBM Patent Disclosure and Licensing Statement Regarding IETF RFC 2338 |date=2003-04-15 |access-date=2013-11-28 |author=Chuck Adams, IBM |publisher=IETF}}</ref> All patents in question have expired.<ref>{{Cite patent|number=US6148410A|title=Fault tolerant recoverable TCP/IP connection router|gdate=2000-11-14|invent1=Baskey|invent2=Dillenberger|invent3=Goldszmidt|invent4=Hunt|inventor1-first=Michael Edward|inventor2-first=Donna Ngar-Ting|inventor3-first=German Sergio|inventor4-first=Guerney Douglass Holloway|url=https://patents.google.com/patent/US6148410A/en}}</ref><ref>{{Cite patent|number=US5371852A|title=Method and apparatus for making a cluster of computers appear as a single host on a network|gdate=1994-12-06|invent1=Attanasio|invent2=Smith|inventor1-first=Clement R.|inventor2-first=Stephen E.|url=https://patents.google.com/patent/US5371852A/en}}</ref> The protocol was refined in 2004 as version 2.{{Ref RFC|3768}} VRRP version 3, the current version, was published in 2010.{{Ref RFC|5798}} == Derivatives == [[Mellanox]] offers MAGP, a proprietary protocol based on VRRP that allows active-active operation.<ref>{{Cite web|title=HowTo Configure MAGP on Mellanox Switches|url=https://community.mellanox.com/s/article/howto-configure-magp-on-mellanox-switches|access-date=2010-01-21}}</ref> [[Foundry Networks]] developed VRRP-E(Extended), a proprietary version of VRRP that avoids a few limitations of RFC 3768<ref>{{Cite web|title=VRRP-Ev2 overview|url=http://docs.ruckuswireless.com/fastiron/08.0.60/fastiron-08060-l3guide/GUID-2D575A2F-2AE4-4B52-AB12-9E963B05B9EE.html|access-date=2021-06-07|website=docs.ruckuswireless.com|language=en-US}}</ref>[https://ftp.hp.com/pub/networking/software/59906030_ch15.pdf] ==See also== * [[Common Address Redundancy Protocol]] (CARP) β a non-proprietary, patent-free, and unrestricted alternative to HSRP and VRRP * [[Gateway Load Balancing Protocol]] β a [[Cisco Systems]] proprietary router redundancy protocol providing load balancing * [[Hot Standby Routing Protocol]] β a Cisco Systems proprietary router redundancy protocol * [[First Hop Redundancy Protocols]] β Lists of default gateway redundancy protocols * [[RSMLT]] ==References== {{reflist}} ==External links== * {{cite web | url = http://www.ietf.org/mail-archive/web/vrrp/current/maillist.html | title = The IETF VRRP mailing list archive}} [[Category:Internet protocols]] [[Category:Routing protocols]] [[Category:First-hop redundancy protocols]]
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)
Pages transcluded onto the current version of this page
(
help
)
:
Template:Cite patent
(
edit
)
Template:Cite web
(
edit
)
Template:Distinguish
(
edit
)
Template:IPaddr
(
edit
)
Template:MACaddr
(
edit
)
Template:Math
(
edit
)
Template:Ref RFC
(
edit
)
Template:Reflist
(
edit
)
Template:Short description
(
edit
)