Re: [IETFMIBS] MIB implementation

"Rohit M (rrohit)" <rrohit@cisco.com> Wed, 31 October 2012 03:20 UTC

Return-Path: <rrohit@cisco.com>
X-Original-To: ietfmibs@ietfa.amsl.com
Delivered-To: ietfmibs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7C421F86C3 for <ietfmibs@ietfa.amsl.com>; Tue, 30 Oct 2012 20:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 h+1O52z3wSPc for <ietfmibs@ietfa.amsl.com>; Tue, 30 Oct 2012 20:20:33 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84721F868E for <ietfmibs@ietf.org>; Tue, 30 Oct 2012 20:20:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7885; q=dns/txt; s=iport; t=1351653633; x=1352863233; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=t0VMFFuMLj2tbwkiFJbfl5u8DmdDr0NoqPc5ykoU8D4=; b=GDS6wW/vb7SCN9sVYsNM2+C7lmkUwp1KLJsZEXEnQ/KfU+Z8hu0Kahgq fRW/wqcBBXOf1IN9C4ASmz+Xl+YJcm40I/40pNVt6TNek/foBk7oriYiH sIVr6x6Xo1tnWR2fxExRGsbUe5VJwIB9DHgcxf8oaNu88eaqpJSL5/T2o U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANuXkFCtJV2b/2dsb2JhbABEgknBNIEIgh4BAQEEEgEaXAIBCBEEAQELHQcyFAkIAQEEARIIGodknE+Rd44Gi3eFWmEDpEyBa4JiDYIZ
X-IronPort-AV: E=Sophos; i="4.80,684,1344211200"; d="scan'208,217"; a="137159419"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2012 03:20:32 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9V3KW56014098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 03:20:32 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 22:20:32 -0500
From: "Rohit M (rrohit)" <rrohit@cisco.com>
To: Guo Peter <Peter.Guo@grassvalley.com>, "ietfmibs@ietf.org" <ietfmibs@ietf.org>
Thread-Topic: MIB implementation
Thread-Index: Ac22XMyAF4LEx/rmS8+7n3xhudKc4gAuYfkg
Date: Wed, 31 Oct 2012 03:20:31 +0000
Message-ID: <1ADD118FF709314D8FD5EF271A835B6E10AA59@xmb-aln-x05.cisco.com>
References: <5DB1F9C75856284BB12FF7E1BD91F58002C78ED6@BL2PRD0410MB350.namprd04.prod.outlook.com>
In-Reply-To: <5DB1F9C75856284BB12FF7E1BD91F58002C78ED6@BL2PRD0410MB350.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.87.163]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004
x-tm-as-result: No--38.568600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_1ADD118FF709314D8FD5EF271A835B6E10AA59xmbalnx05ciscocom_"
MIME-Version: 1.0
Subject: Re: [IETFMIBS] MIB implementation
X-BeenThere: ietfmibs@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF MIB Discussion list <ietfmibs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietfmibs>, <mailto:ietfmibs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietfmibs>
List-Post: <mailto:ietfmibs@ietf.org>
List-Help: <mailto:ietfmibs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietfmibs>, <mailto:ietfmibs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Oct 2012 03:20:36 -0000

Hi Guo,

Vendor should be implementing standards MIBs such as IF-MIB, Entity MIB and Vendor specific MIBs.   Most of the NMS tool does rely on IF-MIB to get interface specific info.  Hence you should support the IF-MIB and that will get this info to  the NMS tool.

Regards
Rohit

From: ietfmibs-bounces@ietf.org [mailto:ietfmibs-bounces@ietf.org] On Behalf Of Guo Peter
Sent: Tuesday, October 30, 2012 10:49 AM
To: ietfmibs@ietf.org
Subject: [IETFMIBS] MIB implementation

Hello,

I am a developer for Grass Valley. Our registration for SNMP is  1.3.6.1.4.1.4947. I have a customer want to inquire about the MAC address of our device. He is trying to get the Physical address of the hardware using Get Request for the 1.3.6.1.2.1.2.2.1.6 and return nothing. Please see the screen capture and comments below. So my question is as a third party vendor we are normally only implementing MIB version 1(or MIB version 2) under our enterprise 1.3.6.1.4.1.4947 tree. So I don't see the iPhyAddress in our tree. So how should implement this for our customer? Or is the our responsibility to do? And is this field a mandatory field we had to implement? Where and how should I do that?



Regards, Peter Guo

Grass Valley Inc.






"Here is what I have found so far - The SNMP configured devices are not replying to the SNMP-Get request for Mib 2 Interfaces. This is necessary for proper identification of connectivity. Spectrum uses the MAC address and compares it with the Switch ARP table to define where the device is connected. If the device is not responding to this OID request, Spectrum has no way to map it to the switch. This hinders fault isolation and troubleshooting. I have attached the results of a MIB 2 query. The device reports no results.  I would look to the engineering folks to see why the device does not respond to a MIB 2 query."