Conference azur::mcc

4419.0. "Trap Addresses on DECbridge 500/600" by QUIVER::WALTER () Wed Jan 20 1993 16:40

		[Cross posted in MOUSE::FDDI conference.]
    
	The following is a clarification of Trap Addresses as implemented
	on the DECbridge 500 & 600 series. There is also some information
	on problems with the SHOW BRIDGE ALL STATUS command in MCC.

BACKGROUND
----------

	First, a little history regarding the implementation of SNMP on 
	the bridges:

	V1.1 -	SNMP functionality was added but only GETs supported, not
		SETs. Since SETs not allowed, RBMS was extended to allow
		IP Address, Default Gateway Address, and Trap Addresses
		to be set through RBMS protocol (ie. ELMS support).

	V1.2 -	SNMP SET capability was added. Now Gateway Address and 
		Trap Addresses can be added through SNMP (IP Address still
		must be set through RBMS or other means). However, in the
		process we created a problem: 

			A new Trap Address Table was created for SNMP, but
			RBMS still pointed to the OLD Trap Address Table.
			As a result, RBMS "adds" and "removes" are working 
			with garbage data! (Translation: We should have
			disabled add/remove of traps through RBMS.)

		We specified in the Release Notes that traps are only 
		supported in the SNMP interface, not ELMS. But then, who
		reads Release Notes?

		Oh, yes, one more thing. Due to an initialization bug, 
		SNMP doesn't work in the 500 series bridges at all.

	V1.2B - (Some early versions of this code referred to as V1.2.2)
		Initialization bug fixed in this version, so SNMP works on
		the 5xx. But there is still the problem with traps and 
		RBMS.

	V1.3 -  (Currently in Field Test.)
		In this version we have disabled access to Trap Addresses
		through RBMS. You can neither read nor write traps.

Of course, there are many other differences between the firmware versions
listed above, but these are the ones related to SNMP and Trap Addresses.

IMPLICATIONS
------------

If you are running V1.1:
	There is no problem reading or setting trap addresses through 
	RBMS. But there are various other reasons why you should upgrade
	to V1.2B (like the ability to do SNMP SETs).

If you are running V1.2:
	The Trap Addresses reported by RBMS are wrong. Use ONLY the SNMP
	interface to access Trap Addresses. You should upgrade to V1.2B,
	especially if code is running on a 500 series bridge.

If you are running V1.2B:
	The Trap Addresses reported by RBMS are still wrong. But at least
	SNMP runs on the 500 series.

When V1.3 becomes available:
	The bridge will no longer support read or write of the trap addresses
	through RBMS. So no more garbage-in, garbage-out.


RELATED MCC BUG
---------------

A number of notes refer to MCC errors when doing a SHOW BRIDGE ALL STATUS
command. We have found that if trap addresses are included in the bridge
response packet, MCC will reject the response with a "ILV invalid value"
error. This appears to be a bug in the Bridge AM of MCC. Bob Harokopus is
looking into this matter. Since V1.3 never sends back trap addresses, this
will not be an issue for V1.3.