Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

3300 SNMP traps

Status
Not open for further replies.

JohnE66

MIS
Mar 23, 2004
44
0
0
GB
We are getting Cold Start traps from the 3300s, but none when we get an alarm status on the switches.

As we are getting the Cold Start it seems we have the basic IP and trap details correct but we are supposed to be able to get threshold and alarms traps too.

Is there anywhere else that this needs to be set up please?

Many thanks
 
You haven't really told us what you have done actually, only what's not working.

What forms have you set up and how are they configured?

give us something to work with at least.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
We have two trap receivers set up and allow all SNMP managers. I have not seen anywhere to set up specific traps to receive. We do get the Cold Start traps as I stated but nothing else. We have had a threshold changed to put the system into both minor and major alarms, but still no SNMP trap.

Is there anywhere to set which particlur traps are sent?
 
So I take it that you have not done any setup in the 3300 in the SNMP forms?

If you have could you provide specifics such as community names and settings.

It is not possible to advise you on what you have not done when you do not provide info on what you have done.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
Yes, the community strings and trap destinations are set up.

As I have said, we receive the Cold Start trap, but cannot see where you can set up to specify that a trap is sent when the switch has an alarm.
 
Just to clarify we need the alerts to go to a non Mitel network management station, SNMPc.
 
Assuming that the programming in the 2 forms on the 3300 are done correctly, it will send the information you require.

There are quite a few conditions mentioned in the help files.

from the help files said:
Conditions
Certain MIBs require the Layer 2 switch IP address to be configured and the controller rebooted before they will work on a CXi or MXe.

Values of type Counter64 can only be retrieved with the SNMP management system in V2 mode.

The SNMP agent supports GET-BULK PDUs in V2 mode. If the management system can be configured to use GET-BULK instead of GET it should be as this will result in less network traffic and quicker data retrieval.

Some of the objects will never change—that is, they are "hard coded" and "not supported".

Writing to the standard MIB objects (RFCs) using SET is not supported and the agent will reply with the error status readOnly.

Some generic MIB browsers present MIB objects which do not have any ACCESS or MAX-ACCESS clause (such as group identifiers, trap OIDs, etc.). Both HP Openview and Adventnet (Mitel Enterprise Manager) fall into this category. An attempt to retrieve data from these objects, or to walk the tree below a node containing only these kinds of objects will fail (the agent will respond noSuchName/noSuchInstance).

When the end of MIB view is encountered the agent will return endOfMib as an error status. Often generic MIB browsers will not handle this correctly or will not display it in a nice fashion. mitelBCMChipType is currently the last OID in the MIB view. If a MIB walk traverses this OID in adventnet browser (EMgr) it will report an error. This can be misleading, allowing the user to form a conclusion that a problem exists where there is none.

If the user generates a request that could take a long time to satisfy (for example a GET-BULK request with a large number of OIDs and/or repeaters), the user must also increase the timeout to allow the 3300 ICP enough time to formulate the response.

Attempts to retrieve data about interfaces (especially Layer 2 switched interfaces) early in the system startup sequence may return noSuchName or noSuchInstance while the hardware is starting up and the tables are being populated. This is normal. Ideally, one should wait for the RFC1215 restart trap before trying to retrieve data from the 3300 ICP.

When loading MIB files, MIB dependencies may be an issue. Generic MIB browsers vary in their strictness with respect to dependencies. HP Openview, for example, can load all the MIBs currently supported; the only dependency is RFC1213. Adventnet, by comparison, has complex dependencies; however, if the right-click menu of a 3300 ICP icon (or the action menu item) Browse MIBs is used, the MIBs are all loaded in the correct order and the MIB browser will remember the dependencies in the future).

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.
 
I have read that thanks and it seems to relate to the management station accessing the switches rather than the switches sending traps to the management station.

Our management station can access the switches using SNMP.
 
Have you loaded the Mitel specific MIBs (found in the SNMP directory on the 3300 software CD) into your management application?



Dale
 
Yes, although the system will also report unknown traps. We have also monitored the network and we do not get an SNMP trap when the threshold changes.

Many thanks
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top