Talk:Virtual Router Redundancy Protocol

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Low-importance).

How can one redirect this article to Virtual Router Redundancy Protocol I think that would be a more appropriate name

Router emphasis

I feel the article is written too strongly as if this technology is only usuable for high-availability gateway. It should be explained as a simple protocol to share a layer 3 IPv4 or IPv6 address between two inter-connected hosts. And this can be used for every horizontally scaling IP(v4/v6) service. I personally use it with two DNS servers and client name-server failover since Windows hosts transistion too slowly from primary to secondary nameserver (resulting in better user-experience). — Preceding unsigned comment added by 109.134.134.75 (talk) 21:03, 23 February 2013 (UTC)[reply]

Load sharing

Can VRRP be used to share two gateways in a load-balancing arrangement? If so, is there a way of setting a "preferred" gateway for different nodes?

Yes, that's actually the only way to perform load-balancing. Given two routers, router1 and router2, create two vrids, e.g. vrid1 and vrid2 with virtual ip addresses ip1 and ip2 respectively. Make both routers members of both vrids, but give router1 a higher priority in vrid1 and give router2 a higher priority in vrid2. Now set some nodes (hosts) to a default gateway of ip1, and the rest to ip2. Under normal operation (both routers up) the load is coarsely balanced between the routers, with router1 serving ip1 and router2 serving ip2. If either router fails the other takes over both ips. Daren Brantley 20:16, 17 November 2006 (UTC)[reply]

VRRP and PAT (Source-NAT)

Can VRRP be used on a network that uses Port Address Translation (PAT) to hide itself from the external network? Will established TCP sessions be reset when a failover takes place?

Yes and yes. For tcp connections to stay up the routers would have to synchronize their port maps AND present the same public IP address.. remember the remote host indexes it's tcp connections with the router's public IP. Daren Brantley 20:29, 17 November 2006 (UTC)[reply]

Open-source firewalls pFsense and Vyatta both offer functionality to syncronize the NAT state table between multiple routers resulting in less disruption. — Preceding unsigned comment added by 109.134.134.75 (talk) 21:05, 23 February 2013 (UTC)[reply]

Is this protocol provably covered by a patent?

The introductory text in the Article unambiguously states that VRRP is "patented and licensed", as if this were a fact.

However, according to the only cited reference, Cisco's "definitive statement" of March 20, 1998 is not so definitive. It merely says that the protocol: "would likely infringe on Cisco's patent #5,473,599". And even if Cisco had made a more forceful assertion (as it did informally a year previous to that "definitive statement"), that would simply be one company's not-so-objective opinion and certainly not something that deserved being restated as a fact in an encyclopedic entry.

So I am going to insert the word "allegedly" to indicate the subjective status of this patent assertion. Rahul (talk) 00:38, 16 September 2010 (UTC)[reply]

I like your suggestion and have changed the wording to identify Cisco specifically as the one questioning, and ask for clarification on this. —fudoreaper (talk) 06:46, 25 February 2013 (UTC)[reply]

Skew Timer Value

On 27th of August 2012 79.45.123.35 added the Skew Timer formula to the Master Election section, noting that this is counted in milliseconds. That is of course meant to be seconds rather than milliseconds as per RFC 3768. RFC 5798 (VRRPv3) has a slightly more elaborate Skew Timer calculated in centiseconds and taking into account the master advertisement interval. So far as there are no objections, I intend to correct the mistake and possibly add description of the enhanced skew timer in VRRPv3. Comments are welcome.

92.108.58.67 (talk) 21:00, 21 March 2013 (UTC)[reply]

VRRP kernel ethtool

Note the user-space ethtool should not be confused with VRRP kernel ethtool. Disambiguation needed? 167.98.51.116 (talk) —Preceding undated comment added 14:14, 20 February 2020 (UTC)[reply]