Re: [VRRP] Backup->Master transition and ARP reply question

Stephen Nadas <stephen.nadas@ericsson.com> Wed, 22 February 2012 14:15 UTC

Return-Path: <stephen.nadas@ericsson.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF5121F8705 for <vrrp@ietfa.amsl.com>; Wed, 22 Feb 2012 06:15:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW4t0NixiLJR for <vrrp@ietfa.amsl.com>; Wed, 22 Feb 2012 06:14:58 -0800 (PST)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 099A021F8700 for <vrrp@ietf.org>; Wed, 22 Feb 2012 06:14:57 -0800 (PST)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q1MEEuOm029402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Feb 2012 08:14:57 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.140]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 22 Feb 2012 09:14:56 -0500
From: Stephen Nadas <stephen.nadas@ericsson.com>
To: Evan Gilman <evan@miami.edu>, "vrrp@ietf.org" <vrrp@ietf.org>
Date: Wed, 22 Feb 2012 09:14:55 -0500
Thread-Topic: [VRRP] Backup->Master transition and ARP reply question
Thread-Index: AczwDXeDfIVvX9njSWGECuerJFO8AgBWKB4g
Message-ID: <450AE4BEC513614F96969DDA34F359342552A59835@EUSAACMS0701.eamcs.ericsson.se>
References: <4F42AB5E.4000409@miami.edu>
In-Reply-To: <4F42AB5E.4000409@miami.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [VRRP] Backup->Master transition and ARP reply question
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Feb 2012 14:15:02 -0000

Hi Evan,

This list is quiet but still the right place for this question. 

IMO the answer to the 1st questions is yes. 

For the 2nd question I guess (in v4 case) you are seeing grat arps before the advertisement from the router assuming vrrp mastership.  My guess would be that the original intent was that the steps were intended to be followed in order but I do not know this for sure.  Remember that 5798 was edited into 1 doc from the v4 rfc and the v6 draft; if there had been a statement in one or the other of the src docs wrt your question I think it would have made it into 5798.  
    
Thanks,
Steve 

-----Original Message-----
From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Evan Gilman
Sent: Monday, February 20, 2012 3:22 PM
To: vrrp@ietf.org
Subject: [VRRP] Backup->Master transition and ARP reply question

Hello all. I have a couple quick questions for you, hopefully there are still people subscribed to this list that know the answers.

1. Section 8.1.2 (Host ARP Requests) of RFC 5798 states that "...the source address of the Ethernet frame of this ARP response is the physical MAC address of the physical router", however I've observed ARP responses with an Ethernet source of the Virtual MAC in products claiming 5798 compliance - is this required for compliance?

2. Section 6.4.2 (Backup) of RFC 5798 has three or four actions to take on the 'If Master_Down_Timer fires' condition, the last of which is 'Transition to the Master state', and the first of which is 'Send an advertisement'. Are these actions written in strict order? In other words, must the actions be executed sequentially in order to be determined 5798 Compliant? Seems to me that they would. It also seems to me that this question should be answered by some sort of RFC guideline, however I've yet to find one.

Thanks in advance for your time, it's very much appreciated.

--
evan

_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www.ietf.org/mailman/listinfo/vrrp