Conference azur::mcc

4128.0. "ASN1/DECmccV1.2/CABLETRON pb ??" by ZTOIS1::VISTA (Renato VISTA, SIS Strasbourg, France) Mon Nov 23 1992 13:09

    
    Hi,
    
    I'm working on a DECmcc/ULTRIX/BMS V1.2.0 platform. I want to manage
    CABLETRON IRM2 (V2.00.00) Management Board, using the private mib
    CABLETRON_MIBDEF.TXT ASN1 file included in DECmcc last kit.
    
    When doing the following command :
    
    MCC>show snmp <cabletron> CABLETRON commsDevice sourceAddr * all attr
    
    ..., instead of a complete of 48-bits Hardware Ethernet Addresses
    (ASN1 datatype : OCTETSTRING) seen by IRM2, I get only the three or
    four first addresses of the list, ie :
    
    		portSourceAddr = %X08002b1da908
    	       sourceAddrBoard = 1
                sourceAddrPort = 1
    
    	...etc...(only for the 4 first addresses in the expected list).
    
    
    BUT, when I use the mcc_tcpip_mq MIB utility, I get the complete list
    of addresses seen by IRM2, ie :
    
    #mcc_tcpip_mq <cabletron> 1 1
    OID>1.3.6.1.4.1.52.1.2.1.7.1
    Object Id: 1.3.6.1.4.1.52.1.2.1.7.1.8.0.43.29.169.8. (please note the
    Value = 1						  decimal HW Address
    							  suffix/index...)
    ...a complete list of 522 addresses...
    
    
    AND, FINALLY, when I specify directly the 5th HW address (not returned
    by DECmcc * command), ie 
    
    MCC>show snmp <cabletron> CABLETRON commsDevice sourceAddr
    			%X02cf1f906523 all attributes
    
    		portSourceAddr = %X02cf1f906523
    	       sourceAddrBoard = 1
                sourceAddrPort = 1
    
    ... the instance is effectively returned !!!
    
    In conclusion, is there any problem with DECmcc and generic usage of
    the * symbol for such an instance table ?? Any problem with Hardware
    Address ASN1 OCTETSTRING datatype ??
    
    Thank you for your replies.
    
    Renato
    
    		

	Renato,
		The SNMP protocol states that the GetNext request should
	return the lexicographically next object. For tabular objects, when
	you use a wildcard, the SNMP AM starts at the beginning of the table
	and fetch all the objects in the table using the GetNext operator.
	The SNMP AM also makes a check that the object sent back is the
	lexinext object. If it is not, then it assumes that the end of the
	table is reached and stops.

		The fourth instance in the table has a value of %X08002b1da908
	while the fifth instance has a value of %X02cf1f906523, which is 
	lexicographically less. Which explains why the table processing
	stops at this point. Ideally the agent should be returning the
	the portSourceAddr in ascending order. 

		This is one restriction which has been lifted in V1.3 of
	the SNMP AM. However, if the agent does not support lexicographiocal
	ordering for the GetNext request, and if there are holes in table
	(i.e. some of the table objects are not implemented) then some
	weird behaviour may be seen. Specifically, some rows in the table
	may be skipped entirely. However, that sort of behaviour will be
	a lot more desirable than what you see now. The best solution still,
	is for the agents to stick to the protocol.

	Rahul.