Re: [VRRP] RFC5798
Stephen Nadas <stephen.nadas@ericsson.com> Thu, 14 October 2010 16:09 UTC
Return-Path: <stephen.nadas@ericsson.com>
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 <vrrp@core3.amsl.com>; 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 <vrrp@core3.amsl.com>; 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 <vrrp@ietf.org>; 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 <stephen.nadas@ericsson.com>
To: Carl Petersen <CPetersen@broadsoft.com>
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: <D64134C7765B58448BEF1C5E0B4BBB1514D67782DD@EXMBXCLUS01.citservers.local>
In-Reply-To: <D64134C7765B58448BEF1C5E0B4BBB1514D67782DD@EXMBXCLUS01.citservers.local>
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" <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 <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2010 16:09:05 -0000
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 remain 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 about 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 scenario or to recover from it? Thanks Carl Petersen
- Re: [VRRP] RFC5798 Stephen Nadas
- Re: [VRRP] RFC5798 Danny J. Mitzel