[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

4989.0. "SNMP AM on ULTRIX question" by ZUR01::SCHNEIDERR () Mon May 03 1993 04:44

Hello,

With MCC V1.2 we was able to register entities supporting only ICMP. Now we run
MCC 1.3 on Ultrix and found out, that we can not register any ICMP only nodes.

We saw with the analyzer, that if we want register a SNMP entity, MCC sends out
a SNMP packet with the Enterprise-Code of the last compiled privat MIB. Is that a
bug or do we have done something wrong?

Roland
T.RTitleUserPersonal
Name		DateLines
4989.1MOLAR::YAHEY::BOSEMon May 03 1993 10:5913
	The SNMP AM V1.3 does mib filtering by doing GetNext operations
	on the Enterprise code of the mibs that are loaded. If the operation
	was successful then the mib is supported. 

	This means that for non-SNMP devices you will see partial registration
	with reason "No Response from entity". But your device should still
	show up on the map and you should be able to do reachability tests
	on it. Let me know if you see a different behaviour.

	Rahul.
4989.2ZUR01::SCHNEIDERRMon May 10 1993 05:11103
Rahul,

O.K., But we have a vendorspecific MIB with code 50 and we want to register a
SNMP node that doesn't support this MIB, then we can't do that. MCC tries to
register this entity three times with the vendor code 50. See the sniffer trace
after.


Thanks Roland



Sniffer Network Analyzer data from 6-May-93 at 08:50:18, unsaved capture data, Page 1




- - - - - - - - - - - - - - - - Frame 1 - - - - - - - - - - - - - - - - -

SUMMARY  Delta T     Destination   Source        Summary
M    1            ODSTS_20.18     [146.67.19.102]  SNMP Next Optical Data System.0

SNMP: ----- Simple Network Management Protocol -----
SNMP: 
SNMP: Version = 0
SNMP: Community = public
SNMP: Command = Get next request
SNMP: Request ID = 1
SNMP: Error status = 0 (No error)
SNMP: Error index = 0
SNMP: 
SNMP: Object = {1.3.6.1.4.1.50.0} (Optical Data System.0)
SNMP: Value  = NULL
SNMP: 

ADDR  HEX                                                ASCII
0000  AA 00 04 00 86 0B 08 00  2B 26 4B 0F 08 00 45 00  ........+&K...E.
0010  00 49 0F AD 00 00 1E 11  40 F9 92 43 13 66 92 43  [email protected]
0020  14 12 06 75 00 A1 00 35  F9 F6 30 82 00 29 02 01  ...u...5..0..)..
0030  00 04 06 70 75 62 6C 69  63 A1 82 00 1A 02 01 01  ...public.......
0040  02 01 00 02 01 00 30 0F  30 82 00 0B 06 07 2B 06  ......0.0.....+.
0050  01 04 01 32 00 05 00                              ...2...



- - - - - - - - - - - - - - - - Frame 2 - - - - - - - - - - - - - - - - -

SUMMARY  Delta T     Destination   Source        Summary
     2    5.0028  ODSTS_20.18     [146.67.19.102]  SNMP Next Optical Data System.0

SNMP: ----- Simple Network Management Protocol -----
SNMP: 
SNMP: Version = 0
SNMP: Community = public
SNMP: Command = Get next request
SNMP: Request ID = 1
SNMP: Error status = 0 (No error)
SNMP: Error index = 0
SNMP: 
SNMP: Object = {1.3.6.1.4.1.50.0} (Optical Data System.0)
SNMP: Value  = NULL
SNMP: 

ADDR  HEX                                                ASCII
0000  AA 00 04 00 86 0B 08 00  2B 26 4B 0F 08 00 45 00  ........+&K...E.
0010  00 49 0F AE 00 00 1E 11  40 F8 92 43 13 66 92 43  [email protected]

Sniffer Network Analyzer data from 6-May-93 at 08:50:18, unsaved capture data, Page 2


0020  14 12 06 75 00 A1 00 35  F9 F6 30 82 00 29 02 01  ...u...5..0..)..
0030  00 04 06 70 75 62 6C 69  63 A1 82 00 1A 02 01 01  ...public.......
0040  02 01 00 02 01 00 30 0F  30 82 00 0B 06 07 2B 06  ......0.0.....+.
0050  01 04 01 32 00 05 00                              ...2...



- - - - - - - - - - - - - - - - Frame 3 - - - - - - - - - - - - - - - - -

SUMMARY  Delta T     Destination   Source        Summary
     3    5.0039  ODSTS_20.18     [146.67.19.102]  SNMP Next Optical Data System.0

SNMP: ----- Simple Network Management Protocol -----
SNMP: 
SNMP: Version = 0
SNMP: Community = public
SNMP: Command = Get next request
SNMP: Request ID = 1
SNMP: Error status = 0 (No error)
SNMP: Error index = 0
SNMP: 
SNMP: Object = {1.3.6.1.4.1.50.0} (Optical Data System.0)
SNMP: Value  = NULL
SNMP: 

ADDR  HEX                                                ASCII
0000  AA 00 04 00 86 0B 08 00  2B 26 4B 0F 08 00 45 00  ........+&K...E.
0010  00 49 0F AF 00 00 1E 11  40 F7 92 43 13 66 92 43  [email protected]
0020  14 12 06 75 00 A1 00 35  F9 F6 30 82 00 29 02 01  ...u...5..0..)..
0030  00 04 06 70 75 62 6C 69  63 A1 82 00 1A 02 01 01  ...public.......
0040  02 01 00 02 01 00 30 0F  30 82 00 0B 06 07 2B 06  ......0.0.....+.
0050  01 04 01 32 00 05 00                              ...2...
4989.3MOLAR::YAHEY::BOSEMon May 10 1993 11:2419
	Roland,

		If the agent followed the SNMP protocol strictly, then the
	following would happen. The SNMP AM would make a GetNext request for
	the enterprise OID (code 50 in your case), and the agent would respond
	with a noSuchName error if it did not support the mib (as in your case).
	The AM would then know that the mib is not supported and take appropriate
	action. Instead, your agent is not responding at all to the request, 
	causing a time-out. The SNMP AM does two more retries (controlled by the 
	UCD Retries MOM attr.), before giving up totally with the error "No
	Response from Entity". This causes a partial registration to occur.

		However, all your available identifiers should have been 
	registered and you should be able to do all normal operations from
	both FCL and the iconic map. If you see anything to the contrary,
	then it is a bug.

	Rahul.
4989.4ZUR01::SCHNEIDERRTue May 11 1993 11:229
Thank you Rahul for your answer. Now I know how it works. We tried two vendor
SNMP boxes. One doesn't return any packet (like you saw in the trace in RE.2).
The other one returnes a "port 161 unreachable" packet.

Now my question: Is it written in some RFC what packet should be returned from 
the agent in such a case? We have to show to the customer that his vendor boxes
are wrong. Our ULTRIX stations work perfect.

Thanks Roland
4989.5MOLAR::YAHEY::BOSETue May 11 1993 11:4426
	I quote from RFC 1098 "A Simple Network Protocol (SNMP)" :


   "Upon receipt of the GetNextRequest-PDU, the receiving protocol entity
   responds according to any applicable rule in the list below:

        (1)  If, for any object name in the variable-bindings field,
             that name does not lexicographically precede the name of
             some object available for get operations in the relevant
             MIB view, then the receiving entity sends to the
             originator of the received message the GetResponse-PDU of
             identical form, except that the value of the error-status
             field is noSuchName, and the value of the error-index
             field is the index of said object name component in the
             received message."

		.
		.
		.


	In other words the agent should return a noSuchName error instead
	of just not responding. (Also look at note #4762).

	Rahul.
4989.6thanksZUR01::SCHNEIDERRMon May 17 1993 07:327
        Rahul.

Thanks a lot, I will tell the RFC number and your answer to the customer. So He
must contact the other vendor.


Regards  Roland