From stephen.nadas@ericsson.com Thu Oct 14 09:09:05 2010 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6CF3A6B11 for ; Thu, 14 Oct 2010 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgWPIpSB7QbF for ; Thu, 14 Oct 2010 09:09:01 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 19C303A693D for ; Thu, 14 Oct 2010 09:09:00 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o9EGAIpJ002095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Oct 2010 11:10:18 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.27]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 14 Oct 2010 12:10:17 -0400 From: Stephen Nadas To: Carl Petersen Date: Thu, 14 Oct 2010 12:10:17 -0400 Thread-Topic: RFC5798 Thread-Index: Actrsj+jwXNTN1NhT8y5zHjQMCtbLQAB+hQg Message-ID: <450AE4BEC513614F96969DDA34F35934149DC427BD@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F35934149DC427BDEUSAACMS0701e_" MIME-Version: 1.0 Cc: "vrrp@ietf.org" Subject: Re: [VRRP] RFC5798 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 16:09:05 -0000 --_000_450AE4BEC513614F96969DDA34F35934149DC427BDEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMO better to ask VRRP list than me, individually, Regards, Steve ________________________________ From: Carl Petersen [mailto:CPetersen@broadsoft.com] Sent: Thursday, October 14, 2010 11:13 AM To: Stephen Nadas Subject: RFC5798 Stephen, I want to ask you a question about this RFC and the VRRP protocol.= Regarding section 6.4.3, bullet points (735) to (765). If 2 vrrp routers became isolated for whatever reason, one router would rem= ain as master, the other would transition from backup to master and send a = gratuitous arp (ipv4 only) to notify remote arp caches. My question is abou= t when the fault is corrected. One router transitions from master to backup= ; the other router still remains as master. The backup router follows (735)= to (765), but the master seemingly does nothing at all. In particular the = now-for-real master does not send a gratuitous arp. This leaves remote arp = caches with the wrong ip/mac value. I'm sure this has been considered. What is typically done to prevent this s= cenario or to recover from it? Thanks Carl Petersen --_000_450AE4BEC513614F96969DDA34F35934149DC427BDEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMO=20 better to ask VRRP list than me, individually,

Regards,

Steve=20

From: Carl Petersen=20 [mailto:CPetersen@broadsoft.com]
Sent: Thursday, October 14, 201= 0=20 11:13 AM
To: Stephen Nadas
Subject:=20 RFC5798

Stephen, I want to ask you a question about this RFC a= nd the=20 VRRP protocol. Regarding section 6.4.3, bullet points (735) to=20 (765).

If 2 vrrp routers became isolated for whatever reason,= one=20 router would remain as master, the other would transition from backup to ma= ster=20 and send a gratuitous arp (ipv4 only) to notify remote arp caches. My quest= ion=20 is about when the fault is corrected. One router transitions from master to= =20 backup; the other router still remains as master. The backup router follows= =20 (735) to (765), but the master seemingly does nothing at all. In particular= the=20 now-for-real master does not send a gratuitous arp. This leaves remote arp= =20 caches with the wrong ip/mac value.

I’m sure this has been considered. What is typic= ally done to=20 prevent this scenario or to recover from it?

Thanks

Carl Petersen

--_000_450AE4BEC513614F96969DDA34F35934149DC427BDEUSAACMS0701e_-- From mitzel@acm.org Thu Oct 14 09:52:08 2010 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B003A6B08 for ; Thu, 14 Oct 2010 09:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7hRmSjcUPu6 for ; Thu, 14 Oct 2010 09:52:06 -0700 (PDT) Received: from web33208.mail.mud.yahoo.com (web33208.mail.mud.yahoo.com [209.191.69.156]) by core3.amsl.com (Postfix) with SMTP id A40AB3A6AB7 for ; Thu, 14 Oct 2010 09:52:06 -0700 (PDT) Received: (qmail 90261 invoked by uid 60001); 14 Oct 2010 16:53:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1287075203; bh=NZ3YVPzkJeDy6fg8SUVhYCvV77rhZpPSd6ruFJLTCKs=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=195pD0tB4icBoACcw+zpZr0TAj2/eXh+9WSdRmJgM6nAcIc/ZmNB5ekXJn1gw7BzKdTlqJyCfTA99WbtCzztjnEtrMm1YkqkdzSneReFpn2cLJ8PjBEfPsrxZu+k2D2Xrc/cHfEnNil6vKlaqKTn0Q5SeGVYu+7yx9whb+/31uY= Message-ID: <139969.89447.qm@web33208.mail.mud.yahoo.com> X-YMail-OSG: sOJLl4sVM1mDyiZw1Xdtr2_brpDa6yXFBhQ6ldYQ5z2WsVk 2m5WqmJWpB_oXgl_USA73Gw0bkceZJxkwPYwgvfcS5BFWMmtFosEIl4MXB5M jdCjTN_lRipvMlxFhJMAh7c1kuZDWI6dXNJvYMNeKMkMSd1FoOQYAOC8FW3b fYXmoczEH7Ii6YzuiOwDoE7T4oXW3UyxaaLyUlBSpGzy5Ug9O1LDwvMptd_J 14thkWQqmr3xv1v9IYJxy7w9oTJEz3YuEok2vAfw6ri_gjv6SIc.5NVmE5w9 GS.BotkixhnpYjBIwpCxsoP64HldwDoL_YE1N9.hhW_qe3WmJIYx3iP2l9.y W4pQ7 Received: from [216.239.45.4] by web33208.mail.mud.yahoo.com via HTTP; Thu, 14 Oct 2010 09:53:22 PDT X-RocketYMMF: danny_j_mitzel X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.106.282862 Date: Thu, 14 Oct 2010 09:53:22 -0700 (PDT) From: "Danny J. Mitzel" To: Carl Petersen , Stephen Nadas In-Reply-To: <450AE4BEC513614F96969DDA34F35934149DC427BD@EUSAACMS0701.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-985233537-1287075202=:89447" Cc: "vrrp@ietf.org" Subject: Re: [VRRP] RFC5798 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mitzel@acm.org List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 16:52:08 -0000 --0-985233537-1287075202=:89447 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable When VRRP is enabled then the associated MAC address is alwaysfixed=C2=A000= -00-5E-00-01-{VRID}. =C2=A0Whether there's a Master failover, ornetwork par= tition and heal, etc. there's no change to the mapping andall client hosts = should be consistent. =C2=A0No action is required. The sole reason for the gratuitous ARP is to increase robustnessthe very fi= rst time VRRP is enabled in the network. =C2=A0Prior to VRRPenable some cli= ent hosts may have cached the router physicalMAC address. =C2=A0When VRRP i= s then enabled the first Mastertransition triggers gratuitous ARP to encour= age client hosts toflush the router physical MAC address if it's in their c= ache. --- On Thu, 10/14/10, Stephen Nadas wrote: From: Stephen Nadas Subject: Re: [VRRP] RFC5798 To: "Carl Petersen" Cc: "vrrp@ietf.org" Date: Thursday, October 14, 2010, 9:10 AM =0A=0A =0A =0A _filtered #yiv163395626 {=0Afont-family:Cambria Math;}=0A _f= iltered #yiv163395626 {=0Afont-family:Calibri;}=0A _filtered #yiv163395626 = {margin:1.0in 1.0in 1.0in 1.0in;}=0A#yiv163395626 P.yiv163395626MsoNormal {= =0AFONT-SIZE:11pt;MARGIN:0in 0in 0pt;FONT-FAMILY:"sans-serif";}=0A#yiv16339= 5626 LI.yiv163395626MsoNormal {=0AFONT-SIZE:11pt;MARGIN:0in 0in 0pt;FONT-FA= MILY:"sans-serif";}=0A#yiv163395626 DIV.yiv163395626MsoNormal {=0AFONT-SIZE= :11pt;MARGIN:0in 0in 0pt;FONT-FAMILY:"sans-serif";}=0A#yiv163395626 A:link = {=0ACOLOR:blue;TEXT-DECORATION:underline;}=0A#yiv163395626 SPAN.yiv16339562= 6MsoHyperlink {=0ACOLOR:blue;TEXT-DECORATION:underline;}=0A#yiv163395626 A:= visited {=0ACOLOR:purple;TEXT-DECORATION:underline;}=0A#yiv163395626 SPAN.y= iv163395626MsoHyperlinkFollowed {=0ACOLOR:purple;TEXT-DECORATION:underline;= }=0A#yiv163395626 SPAN.yiv163395626EmailStyle17 {=0ACOLOR:windowtext;FONT-F= AMILY:"sans-serif";}=0A#yiv163395626 .yiv163395626MsoChpDefault {=0A}=0A#yi= v163395626 DIV.yiv163395626WordSection1 {=0A}=0A=0A=0A =0AIMO =0Abetter to = ask VRRP list than me, individually, =0ARegards,=0ASteve =0A =0A=0A=0AFrom: Carl Petersen =0A[mailto:CPetersen@broadsoft.com]=20 Sent: Thursday, October 14, 2010 =0A11:13 AM To: Stephen Nadas Subject: =0ARFC5798 =0A=0A=0AStephen, I want to ask you a question about this RFC and the =0AVR= RP protocol. Regarding section 6.4.3, bullet points (735) to =0A(765). =0A = =C2=A0 =0AIf 2 vrrp routers became isolated for whatever reason, one =0Arou= ter would remain as master, the other would transition from backup to maste= r =0Aand send a gratuitous arp (ipv4 only) to notify remote arp caches. My = question =0Ais about when the fault is corrected. One router transitions fr= om master to =0Abackup; the other router still remains as master. The backu= p router follows =0A(735) to (765), but the master seemingly does nothing a= t all. In particular the =0Anow-for-real master does not send a gratuitous = arp. This leaves remote arp =0Acaches with the wrong ip/mac value. =0A =C2= =A0 =0AI=E2=80=99m sure this has been considered. What is typically done to= =0Aprevent this scenario or to recover from it? =0A =C2=A0 =0AThanks =0A = =C2=A0 =0ACarl Petersen =0A=C2=A0 =0A -----Inline Attachment Follows----- _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp --0-985233537-1287075202=:89447 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

When VRRP is enabled then the associated MAC = address is always

fixed 00-00-5E-00-01-{VRID}. Whether there= 's a Master failover, or

network partition and heal, etc. there's= no change to the mapping and

all client hosts should be consiste= nt. No action is required.

The sole reason f= or the gratuitous ARP is to increase robustness

the very first ti= me VRRP is enabled in the network. Prior to VRRP

enable som= e client hosts may have cached the router physical

MAC address. &= nbsp;When VRRP is then enabled the first Master

transition trigge= rs gratuitous ARP to encourage client hosts to

flush the router p= hysical MAC address if it's in their cache.

--= - On Thu, 10/14/10, Stephen Nadas <stephen.nadas@ericsson.com> wrote:

From: Stephen Nadas <stephen.nadas@ericsson.com>
Subje= ct: Re: [VRRP] RFC5798
To: "Carl Petersen" <CPetersen@broadsoft.com&g= t;
Cc: "vrrp@ietf.org" <vrrp@ietf.org>
Date: Thursday, October = 14, 2010, 9:10 AM

=0A=0A =0A =0A=0A=0A =0A
= IMO =0Abetter to ask VRRP list than me, individually,
= =0A
Regards,
=0A
Steve =0A

=0A
=0A
=0AFrom: Carl Petersen = =0A[mailto:CPetersen@broadsoft.com]
Sent: Thursday, October 14, = 2010 =0A11:13 AM
To: Stephen Nadas
Subject: =0ARFC5798<= br>
=0A
=0A
=0A
Stephen, I want to ask you a questi= on about this RFC and the =0AVRRP protocol. Regarding section 6.4.3, bullet= points (735) to =0A(765).
=0A
= ;
=0A
If 2 vrrp routers became isolat= ed for whatever reason, one =0Arouter would remain as master, the other wou= ld transition from backup to master =0Aand send a gratuitous arp (ipv4 only= ) to notify remote arp caches. My question =0Ais about when the fault is co= rrected. One router transitions from master to =0Abackup; the other router = still remains as master. The backup router follows =0A(735) to (765), but t= he master seemingly does nothing at all. In particular the =0Anow-for-real = master does not send a gratuitous arp. This leaves remote arp =0Acaches wit= h the wrong ip/mac value.
=0A
=
=0A
I=E2=80=99m sure this has been c= onsidered. What is typically done to =0Aprevent this scenario or to recover= from it?
=0A

=0A
Thanks
=0A

=0A
Carl Petersen
=0A

=0A

-----Inline A= ttachment Follows-----

____________________= ___________________________
vrrp mailing list
vrrp@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/vrrp" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/vrrp

--0-985233537-1287075202=:89447-- From maheshkelkar@gmail.com Fri Oct 22 08:13:13 2010 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0943A676A for ; Fri, 22 Oct 2010 08:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktmcegI9eE18 for ; Fri, 22 Oct 2010 08:13:11 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 9909C3A66B4 for ; Fri, 22 Oct 2010 08:13:10 -0700 (PDT) Received: by wwe15 with SMTP id 15so946551wwe.13 for ; Fri, 22 Oct 2010 08:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=HW0ZmVELML1CE8Pdzi+HwTEQ8xNlbDQmebD1qPupNYI=; b=XhWeicJluE9UooKOzodkEeEdd/zCK4HPlGP0VtwVErs9HQdD0BG5aODBV6d4W1gIOq 6MK9lwTbQwyA5ZOy1oAS/dTJla+RzZxXSsHNmRPfbIBtQa/YBj00J9W8L9xU6Vyt0Lqh YLr+SrUDb5yvDClZC6gUpKr3F4TrXGAA052mI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=V1osDPY+wbce0Bl4bVdrphx5yOc6gdrqIKLxOLziHMJjRwfm8h41IzIC8NSprjVKO7 7IkKC5O6B7meUpzFJkGHn600s8eJZmPiaoM+n1wZSI8as16S1L9GMmNME7KQnWS4jvN9 dmGSxNfywAuhfxRh6CzK9NloY1dJREyPyw5qs= MIME-Version: 1.0 Received: by 10.227.133.135 with SMTP id f7mr2978840wbt.117.1287760488171; Fri, 22 Oct 2010 08:14:48 -0700 (PDT) Received: by 10.216.50.199 with HTTP; Fri, 22 Oct 2010 08:14:48 -0700 (PDT) Date: Fri, 22 Oct 2010 11:14:48 -0400 Message-ID: From: Mahesh Kelkar To: vrrp Content-Type: text/plain; charset=ISO-8859-1 Subject: [VRRP] Any examples of using VRRP in systems/solutions other than Routers? X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 15:13:13 -0000 Hello, Since VRRP is designed to eliminate single point failure, I was wondering if VRRP is used on systems/solutions that do not involve routers. Are there any examples of such usage? Are there any known real world deployments? Are they recommended? I came across some discussions on using VRRP as a failover protocol for Linux Virtual Server (LVS). But I don't know if its deployed or not.. Thanks Mahesh From martinvisser99@gmail.com Sun Oct 24 03:45:30 2010 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3B33A6838 for ; Sun, 24 Oct 2010 03:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQ5WWO4XRvM8 for ; Sun, 24 Oct 2010 03:45:29 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C24143A682C for ; Sun, 24 Oct 2010 03:45:28 -0700 (PDT) Received: by fxm9 with SMTP id 9so1305900fxm.31 for ; Sun, 24 Oct 2010 03:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=UaY+KsQUZjxI2OC+bqr0dG+UuFxlcOyVp9ZcT7u7OAQ=; b=NAhpBCPaLh4A4LqXTYssdyT4AWnnzzIQ6zo10iGbcxs9hKzfLY/cIog5E0aSApzVMH qPU5vPXSssOBs2l68xyaT8m1AhL06go+KHCV43myp+KatDyCsMLOED3jHqjtgH/Ywtrc KWVIe0hHXqA1OMoux6qvcqaIazHV9XrwLFNBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hh/M6cmeD/S2+ts8eDmR8333990C/mhsVRNg3hoyE7eqpWNrOdCq52vWWLfWuRz3df 9xrDllrCSQ47lqy9H8JtZZQYRcpQFNQJmFXwlbxlGHO37XNhT93/zoTyw8SK76LHR+5I bBHYPRp7QmowNSUjsWhiTmvyvdLoksrnSTNu4= MIME-Version: 1.0 Received: by 10.239.133.75 with SMTP id 11mr1423211hbu.31.1287917228615; Sun, 24 Oct 2010 03:47:08 -0700 (PDT) Received: by 10.239.150.211 with HTTP; Sun, 24 Oct 2010 03:47:08 -0700 (PDT) In-Reply-To: References: Date: Sun, 24 Oct 2010 21:47:08 +1100 Message-ID: From: Martin Visser To: Mahesh Kelkar Content-Type: multipart/alternative; boundary=001485f7cc22e9680204935a988d Cc: vrrp Subject: Re: [VRRP] Any examples of using VRRP in systems/solutions other than Routers? X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 10:45:30 -0000 --001485f7cc22e9680204935a988d Content-Type: text/plain; charset=UTF-8 I think you will find it is used a lot on devices employing high availability functions (HA). For instance I know for sure that Nortel's Switched Firewalls and Alteon Load Balancer's use VRRP to implement shared addresses across HA pairs. I am pretty sure many such appliances use it in this fashion just Googling for seemed to show that Citrix Netscalers and Juniper Netscreen use it such a fashion Regards, Martin MartinVisser99@gmail.com On Sat, Oct 23, 2010 at 2:14 AM, Mahesh Kelkar wrote: > Hello, > > Since VRRP is designed to eliminate single point failure, I was > wondering if VRRP is used on systems/solutions that do not involve > routers. > > Are there any examples of such usage? > Are there any known real world deployments? > Are they recommended? > > I came across some discussions on using VRRP as a failover protocol > for Linux Virtual Server (LVS). But I don't know if its deployed or > not.. > > Thanks > Mahesh > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp > --001485f7cc22e9680204935a988d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think you will find it is used a lot on devices employing high avail= ability functions (HA). For instance I know for sure that Nortel's Swit= ched Firewalls and Alteon Load Balancer's use VRRP to implement shared = addresses across HA pairs. I am pretty sure many such appliances use it in = this fashion just Googling for seemed to show that Citrix Netscalers and Ju= niper Netscreen use it such a fashion

Regards, Martin

MartinVisser99@gmail.com

On Sat, Oct 23, 2010 at 2:14 AM, Mahesh = Kelkar <mahe= shkelkar@gmail.com> wrote:

Hello,

Since VRRP is designed to eliminate single point failure, I was
wondering if VRRP is used on systems/solutions that do not involve
routers.

Are there any examples of such usage?
Are there any known real world deployments?
Are they recommended?

I came across some discussions on using VRRP as a failover protocol
for Linux Virtual Server (LVS). But I don't know if its deployed or
not..

Thanks
Mahesh
_______________________________________________
vrrp mailing list
vrrp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/vrrp

--001485f7cc22e9680204935a988d--