IETF Logo Mail Archive

[VRRP] FW: VRRPV3-MIB protocol error trap question

"Kalyan (Srinivas)Tata" <stata@checkpoint.com> Thu, 06 September 2012 03:12 UTC

Return-Path: <stata@checkpoint.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 7C8D021F84C4 for <vrrp@ietfa.amsl.com>; Wed, 5 Sep 2012 20:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.184
X-Spam-Level:
X-Spam-Status: No, score=-8.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-iAJiRbsli7 for <vrrp@ietfa.amsl.com>; Wed, 5 Sep 2012 20:12:28 -0700 (PDT)
Received: from us.checkpoint.com (usmail2.us.checkpoint.com [216.200.240.146]) by ietfa.amsl.com (Postfix) with ESMTP id 46C1F21F84BF for <vrrp@ietf.org>; Wed, 5 Sep 2012 20:12:27 -0700 (PDT)
X-CheckPoint: {50481545-69-8AF0C8D8-FFFF}
Received: from us-ex01.ad.checkpoint.com (us-ex01.ad.checkpoint.com [216.200.240.139]) by us.checkpoint.com (8.14.4/8.14.4) with ESMTP id q863CQ41030730 for <vrrp@ietf.org>; Wed, 5 Sep 2012 20:12:26 -0700
Received: from USEXCHANGE.ad.checkpoint.com ([216.200.240.132]) by US-EX01.ad.checkpoint.com ([216.200.240.139]) with mapi; Wed, 5 Sep 2012 20:12:26 -0700
From: "Kalyan (Srinivas)Tata" <stata@checkpoint.com>
To: "vrrp@ietf.org" <vrrp@ietf.org>
Date: Wed, 05 Sep 2012 20:12:23 -0700
Thread-Topic: [VRRP] VRRPV3-MIB protocol error trap question
Thread-Index: Ac2KPHa8bxMe0JoMTc2sIcYEGsTEgQBnrKzAAACMeNA=
Message-ID: <BE5C948D3F924B40BAAF2F4D9210F5411E4C3F48B1@USEXCHANGE.ad.checkpoint.com>
References: <50460123020000E1000154AA@gwia.alliedtelesyn.co.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_BE5C948D3F924B40BAAF2F4D9210F5411E4C3F48B1USEXCHANGEadc_"
MIME-Version: 1.0
Subject: [VRRP] FW: 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: Thu, 06 Sep 2012 03:12:30 -0000


From: Kalyan (Srinivas)Tata
Sent: Wednesday, September 05, 2012 8:11 PM
To: 'tony vanderpeet'
Subject: RE: [VRRP] VRRPV3-MIB protocol error trap question

Hi Tony,

This was an editing error in which the  vrIdError was not removed from the vrrpV3StatisticsProtoErrReason when vrrpv3RouterVrIdErrors was added as a global counter.

(exactly for the reason you mentioned)

vrrpv3RouterVrIdErrors should be used for counting the number of vrid errors.
Thanks
Kalyan
From: vrrp-bounces@ietf.org<mailto:vrrp-bounces@ietf.org> [mailto:vrrp-bounces@ietf.org]<mailto:[mailto:vrrp-bounces@ietf.org]> On Behalf Of tony vanderpeet
Sent: Monday, September 03, 2012 6:25 PM
To: vrrp@ietf.org<mailto:vrrp@ietf.org>
Subject: [VRRP] VRRPV3-MIB protocol error trap question


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?


Thanks

Tony




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

v2.23.0 | Report a Bug | By Email