[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

6047.0. "Packet Probe registration prob" by NPSS::WADE (Network Systems Support) Thu Jul 14 1994 11:54

    I'm having a problem registering a packet probe device.  This is a 3rd
    party product that supports groups in MIB-II and the RMON MIB.  The
    registration returns with a partial registration error.
    
    I got a trace that shows DECmcc sending out a getnext against 
    1.3...4.36 (DEC Vendor MIB).  The probe does not respond to this
    request.  
    
    Why is DECmcc sending this getnext to a device that does not support
    the DEC Vendor MIB?
    
    Thanks,
    Bill

T.R Title User Personal
Name Date Lines

6047.1 Problem of Packetprobe! BIKINI::KRAUSE CSC Network Management/Hubs Fri Jul 15 1994 05:14 21

T.R	Title	User	Personal Name	Date	Lines
6047.1	Problem of Packetprobe!	BIKINI::KRAUSE	CSC Network Management/Hubs	`Fri Jul 15 1994 05:14`	21
	> I got a trace that shows DECmcc sending out a getnext against > 1.3...4.36 (DEC Vendor MIB). The probe does not respond to this > request. This is a known problem (at least to me...). A fix would require a firmware change to the Packetprobe. But since the firmware is made by Frontier, not DEC, a fix could take a while. Anyway, you should escalate (IPMT/CLD) this problem against the DECpacketprobe 90 (DERMN) to get some attention. It's definitely not MCC's fault! > Why is DECmcc sending this getnext to a device that does not support > the DEC Vendor MIB? Because it tries hard to figure out which private MIBs are supported by a particular device during registration. Any SNMP agent is supposed to return the next following item or 'no such name' to a request for a nonexistent MIB branch. Just no resonse at all is a fault and does not conform to RFC1157. I've seen quite a few SNMP agents with this mis-behaviour, but that's no excuse. *Robert

>    I got a trace that shows DECmcc sending out a getnext against 
>    1.3...4.36 (DEC Vendor MIB).  The probe does not respond to this
>    request.  

This is a known problem (at least to me...). A fix would require a
firmware change to the Packetprobe. But since the firmware is made by 
Frontier, not DEC, a fix could take a while. Anyway, you should escalate 
(IPMT/CLD) this problem against the DECpacketprobe 90 (DERMN) to get 
some attention. It's definitely not MCC's fault!

>    Why is DECmcc sending this getnext to a device that does not support
>    the DEC Vendor MIB?

Because it tries hard to figure out which private MIBs are supported by
a particular device during registration. Any SNMP agent is supposed to
return the next following item or 'no such name' to a request for a
nonexistent MIB branch. Just no resonse at all is a fault and does not 
conform to RFC1157. I've seen quite a few SNMP agents with this 
mis-behaviour, but that's no excuse.

*Robert