Conference azur::mcc

The same scenario described in .0 is occuring at a customer's site.  The 
customer has Chipcom concentrators, Xyplex servers, and DECserver 300s all 
running SNMP with traps enabled.  

All of the servers (DEC and Xyplex) are registered as SNMP entities.  None
of the Chipcom entities are registered. 

I defined an alarm Occurs rule to monitor all SNMP entities for "ANY EVENTS".
Next we rebooted a Xyplex server.  Lo 'n behold, the alarm fires showing a
Chipcom concentrator as the device generating an enterpriseSpecific event = 11.

So, I thought maybe this is legit and something is really going on with the 
Chipcom unit.  Next, I tried defining an alarm Occurs rule specifically for
the Xyplex server to monitor for "ANY EVENTS".  Then we tried accessing the 
server in question with an invalid password.  This I thought would create
and authorization trap.  So now the alarm fires showing a different Chipcom
concentrator as the entity generating the trap (still not registered).  The
trap was another enterpriseSpecific event = ??.

I don't understand what's going on here.  Could someone please enlighten me?

This note has been in here for over a month with no response, and I'm 
hesitant in QARing these types of issues because I realize that it may be
a result of my own ignorance.  But, I do need an answer for a customer who
is trying to get MCC running in a production environment.  If this type of
behaviour needs to be QAR'd for a more immediate response, please advise.

Thanks.

Merlin

	Merlin,
		The behaviour is very strange indeed. Seems like somewhere
	along the way the matching up of entities is failing.

		Since both Alarms FM and SNMP AM is involved in this problem
	it may make sense to try and isolate where the problem lies.

	So, can you bypass alarms  and issue a plain getevent directive from
	FCL and see what comes out in the output.

	MCC> GETEVENT SNMP * ANY EVENT, FOR DUR 02:00:00

	(The above command is for V1.2. For V1.3 you have to use 
	  'ANY CONFIG EVENT' ).

	Rahul.

Rahul,

I did what you suggested in -1.  Follwoing is the setup and results.

In our demo center we have two devices running SNMP.  One is a Proteon p4100
router, and the other is a DECagent 90.

	p4100 = 	"stotkr"   IP addr 16.77.64.162
	DECagent 90 = 	"agent007" IP addr 16.77.64.182

I got into MCC FCL and issued the following command:

MCC> getevent snmp * any config event

Next I forced a reload of the Proteon router (16.77.64.162).  I received the
following trap/event:


SNMP LOCAL_NS:.stotkr
AT  1-APR-1993 10:04:40 CONFIGURATION EVENTS

Successfully received event:
Event: coldStart
A coldStart trap was received:
                             enterprise = "1.3.6.1.4.1.1.1.1.41"
                             agent-addr = 16.77.64.162
                           generic-trap = coldStart
                          specific-trap = 0
                             time-stamp = 848

This looks OK, and is what one would expect.

I reissued the getevent as follows:

MCC> getevent snmp * any config event

Then I restarted the DECagent 90 by doing a "Reset Agent".  I received the 
followingtrap/event:


SNMP LOCAL_NS:.stotkr
AT  1-APR-1993 10:05:36 CONFIGURATION EVENTS

Successfully received event:
Event: linkUp
A linkUp trap was received:
                             enterprise = "1.3.6.1.4.1.1.1.1.41"
                             agent-addr = 16.77.64.162
                           generic-trap = linkUp
                          specific-trap = 0
                             time-stamp = 6440
                                ifIndex = 1


I tested it a third time by issuing the following MCC command:

MCC> getevent snmp agent007 any config event

Then I restarted the DECagent 90 by doing a "Reset Agent", and I also
tried to force an authenticationFailure by issuing several bogus passwords
when logging into the DECagent 90 console port.  Nothing happened.  I received 
no traps from the DECagent or the p4100.  I verified that Traps were enabled
on the DECagent and that the the Trap community name was set to "public" and 
the IP Address for traps was set to my management station.

As you can see the IP agent-addr is that of the p4100, not the DECagent 90.
This is consistent with the what I've seen at the cuatomer's site, and in
our demo center before as described in .1 and .0.


Do you have any other ideas as to how we may figure this thing out?

Thanks

Merlin

	Rahul,

	The proteon device sends two generic traps "coldstart" and 
	"linkup" when you reset it. Thus you received two traps from
	Proteon. The trap from the DECagent does not seem to make it to
	the DECmcc station. There might be a problem with the configuration.

	Use the 'for duration' qualifier to ensure that none of the traps
	are lost when you are busy re-issuing the getevent directive. 

	Rahul.