Re: [IETFMIBS] MIB implementation

Guo Peter <Peter.Guo@grassvalley.com> Tue, 30 October 2012 14:30 UTC

Return-Path: <Peter.Guo@grassvalley.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 7DC8121F8599 for <ietfmibs@ietfa.amsl.com>; Tue, 30 Oct 2012 07:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.486
X-Spam-Level:
X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 zLWAAS-YW7Ex for <ietfmibs@ietfa.amsl.com>; Tue, 30 Oct 2012 07:30:46 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id B998021F8596 for <ietfmibs@ietf.org>; Tue, 30 Oct 2012 07:30:46 -0700 (PDT)
Received: from mail133-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Tue, 30 Oct 2012 14:30:45 +0000
Received: from mail133-ch1 (localhost [127.0.0.1]) by mail133-ch1-R.bigfish.com (Postfix) with ESMTP id 156CB2022D; Tue, 30 Oct 2012 14:30:45 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.85; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -29
X-BigFish: PS-29(zz98dI9371Id6eah146fI542M1432Izz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received-SPF: pass (mail133-ch1: domain of grassvalley.com designates 157.56.240.85 as permitted sender) client-ip=157.56.240.85; envelope-from=Peter.Guo@grassvalley.com; helo=BL2PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ;
Received: from mail133-ch1 (localhost.localdomain [127.0.0.1]) by mail133-ch1 (MessageSwitch) id 1351607443450169_28391; Tue, 30 Oct 2012 14:30:43 +0000 (UTC)
Received: from CH1EHSMHS034.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail133-ch1.bigfish.com (Postfix) with ESMTP id 6216C3C0050; Tue, 30 Oct 2012 14:30:43 +0000 (UTC)
Received: from BL2PRD0410HT005.namprd04.prod.outlook.com (157.56.240.85) by CH1EHSMHS034.bigfish.com (10.43.70.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 30 Oct 2012 14:30:40 +0000
Received: from BL2PRD0410MB350.namprd04.prod.outlook.com ([169.254.2.181]) by BL2PRD0410HT005.namprd04.prod.outlook.com ([10.255.99.40]) with mapi id 14.16.0233.002; Tue, 30 Oct 2012 14:30:40 +0000
From: Guo Peter <Peter.Guo@grassvalley.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Thread-Topic: [IETFMIBS] MIB implementation
Thread-Index: Ac22XMyAF4LEx/rmS8+7n3xhudKc4gAHdEaAAAwLB8A=
Date: Tue, 30 Oct 2012 14:30:40 +0000
Message-ID: <5DB1F9C75856284BB12FF7E1BD91F58002C78F69@BL2PRD0410MB350.namprd04.prod.outlook.com>
References: <5DB1F9C75856284BB12FF7E1BD91F58002C78ED6@BL2PRD0410MB350.namprd04.prod.outlook.com> <20121030084321.GA95415@elstar.local>
In-Reply-To: <20121030084321.GA95415@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [71.219.80.113]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: grassvalley.com
X-Mailman-Approved-At: Tue, 30 Oct 2012 07:35:12 -0700
Cc: "ietfmibs@ietf.org" <ietfmibs@ietf.org>
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: Tue, 30 Oct 2012 14:30:47 -0000

Thanks JS. I think I got my answers now. 
Regards, Peter

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
Sent: Tuesday, October 30, 2012 2:43 AM
To: Guo Peter
Cc: ietfmibs@ietf.org
Subject: Re: [IETFMIBS] MIB implementation

Hi,

you seem to have fairly basic questions related to the usage of SNMP and I am not sure this is the right place to get help. But anyway, if your device has network interfaces (very likely ;-), you should implement the IF-MIB. This MIB module defines among other things the OID 1.3.6.1.2.1.2.2.1.6. And note, you implement standard MIB objects under the OID they are registered; no need to copy stuff into your enterprise branch. Interoperability rests on the idea that everybody implementing a standard MIB module like say the IF-MIB does it with the same OIDs so that management applications can work with different devices.

/js

On Tue, Oct 30, 2012 at 05:19:19AM +0000, Guo Peter wrote:
> 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."
> 
> 


> _______________________________________________
> IETFMIBS mailing list
> IETFMIBS@ietf.org
> https://www.ietf.org/mailman/listinfo/ietfmibs


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>