Re: [Disman] Event MIB Implementation Survey

Benoit Claise <bclaise@cisco.com> Wed, 11 August 2004 16:34 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17271 for <disman-archive@lists.ietf.org>; Wed, 11 Aug 2004 12:34:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvsK-00067V-JQ; Wed, 11 Aug 2004 12:22:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buvlt-0004Tu-5b for disman@megatron.ietf.org; Wed, 11 Aug 2004 12:16:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16312 for <disman@ietf.org>; Wed, 11 Aug 2004 12:16:10 -0400 (EDT)
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buvqb-0002LA-3Y for disman@ietf.org; Wed, 11 Aug 2004 12:21:10 -0400
Received: from [192.168.0.3] (ams-clip-vpn-dhcp4293.cisco.com [10.61.80.196]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i7BGFVg08298; Wed, 11 Aug 2004 18:15:31 +0200 (CEST)
Message-ID: <411A4623.7030309@cisco.com>
Date: Wed, 11 Aug 2004 18:15:31 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
Subject: Re: [Disman] Event MIB Implementation Survey
References: <00b601c41b44$1c123d60$7f1afea9@oemcomputer> <007801c4531b$346875a0$7f1afea9@oemcomputer> <4119F425.1010105@cisco.com>
In-Reply-To: <4119F425.1010105@cisco.com>
Content-Type: multipart/alternative; boundary="------------020507020504050202020708"
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "Disman (E-mail)" <disman@ietf.org>
X-BeenThere: disman@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Distributed Management <disman.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/disman>
List-Post: <mailto:disman@ietf.org>
List-Help: <mailto:disman-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=subscribe>
Sender: disman-bounces@ietf.org
Errors-To: disman-bounces@ietf.org

Benoit Claise wrote:

> Hi Randy,
>
> Sorry for the late reply.
> Note that some URLs below might require a www.cisco.com login.
>
>Implementation Survey for RFC 2981, Event MIB
>
>_Module:_ DISMAN-EVENT-MIB
>
>_Implementation Source:_ 
>Cisco IOS
>	Release 12.0(12)S was based on the draft-ietf-disman-event-mib-10.txt
>	Release 12.2(4)T is compliant to RFC2981
>	http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1834/products_feature_guide09186a00800801fd.html
>	http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00800c391a.html
>  
>
>_Management Application / Agent:_ Agent
>  
>
> <>_GROUPs:_
> dismanEventResourceGroup (y/n): y
> dismanEventTriggerGroup (y/n): y
> dismanEventObjectsGroup (y/n): y
> dismanEventEventGroup (y/n): y
> dismanEventNotificationObjectGroup (y/n): y
> dismanEventNotificationGroup (y/n): y
>
> _OBJECTs:_
> mteTriggerTargetTag (ro/rw): ro
> mteEventSetTargetTag (ro/rw): ro
> mteTriggerValueIDWildcard (ro/rw): rw
> mteTriggerContextNameWildcard (ro/rw): ro
> mteObjectsIDWildcard (ro/rw): rw
> mteEventSetContextNameWildcard (ro/rw): ro

Actually, when I wrote ro, I wanted to say that remote monitoring and 
context wildcarding are not implemented.
So potentially, the right answer should: no

Regards, Benoit

>
> _Deployment / Operational Experience:_
> We have a couple of working examples posted on www.cisco.com
> - The example monitors the locIfInputQueueDrops MIB object for increases
> http://www.cisco.com/en/US/customer/products/hw/routers/ps133/products_white_paper09186a00801a5a68.shtml
>
> - A combined exampled of the EVENT and EXPRESSION MIBs
> http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a008023267a.shtml
>
> Some other working examples will be posted soon:
> - Customized notification.
> A trigger will monitor the status of the ifOperStatus snmp-variable of 
> all the interfaces. When this value changes for one of the interfaces, 
> then a snmp-trap will be sent that will contain some customized 
> fields: ifIndex, ifDescr, ifType, sysLocation, sysName.
> This example uses the existence + notification functionalities of the 
> EVENT-MIB
>
> - Writing the new configuration automatically to a tftp server.
> A trigger will monitor the status of the ccmHistoryRunningLastChanged 
> snmp-variable. When the value
> changes (which means that the config was possibly changed), a copy of 
> the current config will be sent to a server via tftp.
> This example uses the existence + SNMPSet functionalities of the EVENT-MIB
>
> - Backup interface
> A trigger will monitor the status of the ifInOctets snmp-variable of a 
> specific the interface. When the delta reaches a threshold, a 
> secondary line will be brought up using ifOperStatus. When the delta 
> goes below a threshold then the secondary line will be shut down.
> This example uses the threshold + SNMPSet functionalities of the 
> EVENT-MIB
>
>_Comments:_
>This MIB has been implemented for a couple of years already, but not widely used.
>The first issue is that not many customers knew about it.
>I presented a "Fault Management" update at 2 big events recently (total: 300 customers). After presenting the EVENT MIB, I asked a few questions. To be perfectly accurate, the questions were for both EVENT & EXPRESSION MIB, as those 2 MIBs go along together. The EXPRESSION MIB will triger another email later on; anyway the conclusions are useful for the EVENT MIB.
>	1. Who knew about this MIBs before Networkers?
>           Just one of two hands up
>        2. Who consider those 2 MIBs useful in their environments?
>           A majority of hands up
>        3. Who will be playing with those 2 MIBs back home?
>           I would say 1/3 of the audience.
>The second issue is that this MIB is not easy to set up. For example, the indexing must be clearly explained with one example. So more examples should be posted to help the easier deployement.
>
>Customizing the events in the network elements in time consuming. We don't want to loose the configuration in case of network element reload. The EVENT MIB persistence was introduced
>http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087bdc.html
>
>Regards, Benoit.
>
>  
>