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

Evan Gilman <evan@miami.edu> Mon, 20 February 2012 20:22 UTC

Return-Path: <evan@miami.edu>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CA10121F87C8 for <vrrp@ietfa.amsl.com>; Mon, 20 Feb 2012 12:22:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id j9VIsYM7kUrA for <vrrp@ietfa.amsl.com>; Mon, 20 Feb 2012 12:22:30 -0800 (PST)
Received: from mail-tel.cgcent.miami.edu (mail-tel.cgcent.miami.edu []) by ietfa.amsl.com (Postfix) with ESMTP id B83FC21F87C4 for <vrrp@ietf.org>; Mon, 20 Feb 2012 12:22:29 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.73,452,1325480400"; d="scan'208";a="9084866"
Received: from umex002.cgcent.miami.edu ([]) by mail-tel.cgcent.miami.edu with ESMTP/TLS/AES128-SHA; 20 Feb 2012 15:22:28 -0500
Received: from [] ( by smtp.umail.miami.edu ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Feb 2012 15:22:28 -0500
Message-ID: <4F42AB5E.4000409@miami.edu>
Date: Mon, 20 Feb 2012 15:21:50 -0500
From: Evan Gilman <evan@miami.edu>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: <vrrp@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Subject: [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: Mon, 20 Feb 2012 20:22:31 -0000

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.