Conference 7.286::fddi

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

		[Cross posted in NOTED::MCC 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.
		
    

    Having read the relase note, which I agree is seldom done, I tried many
    times to SET/ADD/CREATE a trap address on a DECbridge 610 and 620 with
    SNMP.  Trying to follow the release notes and using DECmcc SNMP AM I
    have not been able to get it to work.  
    
    I am hoping that someone out there has, and would be willing to provide
    an example.
    
    Thanks,
    Steve Woestemeyer
    CSC/CS 

The following commands and responses from MCC illustrate the method to 
manage Trap Addresses on the bridge. The IP Address of the test bridge
is 16.21.16.128, and its Read/Write Community string is its hardware
address. Note that the DEC vendor mib must be loaded in MCC.


	**************************************************
	**  Add new address 1.2.3.4 to Trap Table	**
	**************************************************

MCC> set snmp 16.21.16.128 dec ema eauth1 eauthtrapusertable 1.2.3.4 -
_MCC> eauthtrapuseraddr 1.2.3.4, by password "08002b2ffd7d"

SNMP 16.21.16.128 dec ema eauth1 eauthTrapUserTable 1.2.3.4
AT  5-JAN-1993 16:12:29 Identifiers

Examination of Attributes Shows
                      eauthTrapUserAddr = 1.2.3.4


	**************************************************
	**  Show all addresses in Trap Table        	**
	**************************************************

MCC> show snmp 16.21.16.128 dec ema eauth1 eauthtrapusertable * -
_MCC> eauthtrapuseraddr

SNMP 16.21.16.128 dec ema eauth1 eauthTrapUserTable 1.2.3.4
AT  5-JAN-1993 16:53:48 Identifiers

                      eauthTrapUserAddr = 1.2.3.4

SNMP 16.21.16.128 dec ema eauth1 eauthTrapUserTable 16.21.16.116
AT  5-JAN-1993 16:53:49 Identifiers

                      eauthTrapUserAddr = 16.21.16.116


	**************************************************
	**  Delete address 1.2.3.4 from Trap Table  	**
	**************************************************

MCC> set snmp 16.21.16.128 dec ema eauth1 eauthtrapusertable 1.2.3.4 -
_MCC> eauthtrapuserstatus invalid, by password "08002b2ffd7d"

SNMP 16.21.16.128 dec ema eauth1 eauthTrapUserTable 1.2.3.4
AT  5-JAN-1993 17:03:52 Characteristics

Examination of Attributes Shows
                    eauthTrapUserStatus = invalid


	**************************************************
	**  Show all addresses in Trap Table        	**
	**************************************************

MCC> show snmp 16.21.16.128 dec ema eauth1 eauthtrapusertable * -
_MCC> eauthtrapuseraddr

SNMP 16.21.16.128 dec ema eauth1 eauthTrapUserTable 16.21.16.116
AT  5-JAN-1993 17:04:24 Identifiers

                      eauthTrapUserAddr = 16.21.16.116

    Thanks very much for the example, it worked great.  I think I tried
    every combination/possiblity except the right one.  The DECbridge
    release note/SNMP Agent Configuration Guide was not real clear on how
    to set the TRAP Addresses.
    
    Again Thanks,
    Steve