[VRRP] VRRPV3-MIB protocol error trap question

"tony vanderpeet" <tony.vanderpeet@alliedtelesis.co.nz> Tue, 04 September 2012 01:25 UTC

Return-Path: <tony.vanderpeet@alliedtelesis.co.nz>
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 BC67221F861C for <vrrp@ietfa.amsl.com>; Mon, 3 Sep 2012 18:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.238
X-Spam-Level: *
X-Spam-Status: No, score=1.238 tagged_above=-999 required=5 tests=[AWL=1.237, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UXI6XuwkyDDF for <vrrp@ietfa.amsl.com>; Mon, 3 Sep 2012 18:25:32 -0700 (PDT)
Received: from gate.alliedtelesyn.co.nz (gate.alliedtelesyn.co.nz []) by ietfa.amsl.com (Postfix) with SMTP id DEA7621F8604 for <vrrp@ietf.org>; Mon, 3 Sep 2012 18:25:31 -0700 (PDT)
Received: (qmail 1360 invoked from network); 4 Sep 2012 01:25:23 -0000
Received: from mmarshal2-dx.alliedtelesyn.co.nz (HELO mailmarshall.alliedtelesyn.co.nz) ( by gate-int.alliedtelesyn.co.nz with SMTP; 4 Sep 2012 01:25:23 -0000
Received: from gwia.alliedtelesyn.co.nz (Not Verified[]) by mailmarshall.alliedtelesyn.co.nz with MailMarshal (v6, 2, 0, 2977) id <B504558730000>; Tue, 04 Sep 2012 13:25:07 +1200
Received: from CHCDOM1-MTA by gwia.alliedtelesyn.co.nz with Novell_GroupWise; Tue, 04 Sep 2012 13:25:15 +1200
Message-Id: <50460123020000E1000154AA@gwia.alliedtelesyn.co.nz>
X-Mailer: Novell GroupWise Internet Agent 8.0.2
Date: Tue, 04 Sep 2012 13:24:51 +1200
From: "tony vanderpeet" <tony.vanderpeet@alliedtelesis.co.nz>
To: <vrrp@ietf.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part56674E73.0__="
Subject: [VRRP] VRRPV3-MIB protocol error trap 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: Tue, 04 Sep 2012 01:27:20 -0000

I am implementing the protocol error trap in the VRRPV3 MIB and have spotted a possible hole in the MIB. I wonder if this was picked up in discussions and a work-around devised? 

When an advertisement is received with an unrecognised VR ID, a protocol error trap is generated, with the object vrrpv3StatisticsProtoErrReason. This object has value vrIdError(4) in this case, but what should the index of the object be? In particular, what should the VR ID part of the index be? 

I am inclined to create a variable binding with a fake OID using the unrecognised VR ID, since this will actually convey the information required (which VR ID is invalid, and the address type and ifIndex). 

What, if any, discussion has taken place around this issue, and was there any conclusion reached? 


Tony van der Peet
Software Architect
Allied Telesis Labs Limited
27 Nazareth Ave
Christchurch, NZ
Tel: +64-3-3399532 (DDI)
Mob: +64-27-2091860