SNMP trapping PRI channels up/down

Hi guys.
I am re-configuring some routers to generate traps for our new monitoring tool.
I have noticed that after I applied the snmp trap configs that we are getting traps for PRI channels (30 voice channels), which I wouldn´t like to. This happens when users are using the voice channels on demand. When they hang up, the used channel goes down and I get a trap.
Basically, regargint the controller, the only interface that I must monitor is the signaling one (my case is the channel 0/3/0:15) or if the entire controller goes down.
Below, the snmp trap config:
snmp-server ifindex persist
snmp-server trap-source Loopback0
snmp-server enable traps snmp linkdown linkup coldstart warmstart
snmp-server enable traps envmon
snmp-server enable traps isdn layer2
snmp-server enable traps isdn chan-not-avail
snmp-server enable traps isdn ietf
snmp-server enable traps bgp
snmp-server enable traps hsrp
snmp-server enable traps ipsla
snmp-server enable traps voice poor-qov
Could you please help me to figure out how I can solve this?
Also, if you guys have any other advises and more ways to monitor the voice environment.
Thanks in advance

Duplicate post.
Go HERE.

Similar Messages

Monitoring PRi's with snmp traps

I am looking to monitor when my pri's go down and generate a trap.
Is this the best way:
snmp-server enable traps isdn layer2
or are there some other traps that I can enable?
Thanks,

Once I got my SNMP host to accept the correct attribute and configure the event trap all I had to do was add the trap command to the router. I then bounced one of my low usage PRI's (which had 0 calls on it ) and got the following event traps on the SNMP host:
Minor
May 19, 2010 2:21:00 PM EDT
A demandNbrLayer2Change notification has been received indicating that a D-channel on Rtr_Cisco device, named has layer 1 active but layer 2 not established. Interface Index = 83 Link Status = ISDNLinkInTransition
System
May 19, 2010 2:21:01 PM EDT
System
Major
May 19, 2010 2:20:59 PM EDT
A demandNbrLayer2Change notification has been received indicating that a D-channel on Rtr_Cisco device, named has both layers 1 and 2 inactive. Interface Index = 83 Link Status = ISDNLinkDown
System
May 19, 2010 2:21:00 PM EDT
System
It doesn't tell you specifically which interface is down but at least it narrows it down to the gateway/router. Most of our gateways have only one PRI anyway.
We use Spectrum One Click for network monitoring.
Here is L2 back on line:
May 19, 2010 2:21:01 PM EDT
A demandNbrLayer2Change notification has been received indicating that a D-channel on Rtr_Cisco device, named has layer 1 active and layer 2 established. Interface Index = 83 Link Status = ISDNLinkUp
System

Link down and Link Up Snmp trap C#

Hi i've configure my cisco router to receive the SNMP traps if the link goes up or down. However i found out that when i plugged out the cable i'm not receiving any link down on the network management system. Until i plugged in again the link will then show up or down state. May i know whats the reason why i can't receive the link down when i plugged out my cable?

If your router has only fa0/0 as active interface, then this would be the interface that the router would use to communicate with the network management system. However when you unplug that interface now the router has no interface that it can use to send the link down trap to the network management system.
HTH
Rick

BGP Peer down monitoring through SNMP Traps

Hello,
I'm trying to figure out how I can monitor with BGP peer went down using SNMP traps or any other methods that are out there. Basically I would like to get a trap that tells me the IP address of the peer that went down.
Looking over the SNMP MIBs for BGP all i can find is snmp traps that tell me there was a change in states in BGP, but don't say which neighbor.
Is there any way to get such information? Would I have to use EEM with some script? This seems like a very common thing that people would want to know.
Thank you in advance,
Tom

SNMP notifications can be configured on the router and GET operations can be performed from an external management station only after BGP SNMP support is enabled.
SUMMARY STEPS
1. enable
2. configure terminal
3. snmp-server enable traps bgp [state-changes {[all] [backward-trans] [limited]}] | [threshold prefix]
4. exit

SNMP Trap if a FEX goes down

hello,
need some assistance or help. I have a Nexus 7009 with a FEX N2K-C2248PQ connected. If the N2K goes down (e.g. power down) a syslog event is generated but no snmp-trap from the N7K to the snmp server. Interface up/downs or power supply failures are traped. This is the syslog event:
2014 Feb 13 10:47:47.594 n7009 %FEX-2-NOHMS_ENV_FEX_OFFLINE: FEX-113 Off-line (Serial Number xxxxxxxxx)
is there anybody with an idea?

We've found no solution out-of-the-box, even after some intense research.
But we implemented a simple workaround: Embedded Event Manager Applet. (EEM)
event manager applet EM-CHECK-FEX
description "Checks FEX for availability because no trap would be send"
event syslog occurs 1 pattern "FEX-2-NOHMS_ENV_FEX_OFFLINE"
action 100 snmp-trap strdata "FEX changed to OFFLINE"
action 101 syslog priority notifications msg TRAP_SEND: FEX changed to OFFLINE
The EEM tracks the occurence of the specific syslog-pattern.
If the syslog-pattern in question appears, a snmp-trap will be send.

WLC 5508 - SNMP traps

OK, so I'm at wit's end with this one now.
I configured my SNMP items on the controller and let it roll.
I started to watch my SNMP monitor (SNMPc Management Console by CastleRock) and saw some life from my controller. Yay, woot and dance.
I then started narrowing down the SNMP trap controls because I was getting more than what I want/need currently. I really just want to know if an AP falls off the network or if the controller's link drops.
I continued to get alerts that were just not desireable at this point.
The traps were similar to this:
ciscoLwappDot11ClientAssocNacAlert [1] cldcClientMacAddress.0.36.214.60.32.32 (DisplayString): 00:24:d6:3c:20:20 [2] cldcClientWlanProfileName.0.36.214.60.32.32 (DisplayString): Wireless [3] cldcClientIPAddress.0.36.214.60.32.32 (IpAddress): 172.31.19.101 [4] cldcApMacAddress.0.36.214.60.32.32 (DisplayString): 00:08:30:39:6c:80 [5] cldcClientQuarantineVLAN.0.36.214.60.32.32 (Integer): 0 [6] cldcClientAccessVLAN.0.36.214.60.32.32 (Integer): 119
I couldn't find the culprit, so I turned off (unchecked) all trap controls in the web interface and then verified in the CLI with "show trapflags".
I continue to get these same messages.
Any ideas?
Model: AIR-CT5508-K9
Version: 7.2.103.0

I went through the entire log (about 2000 lines) and almost all are this same type:
(Cisco Controller) >show traplog
Number of Traps Since Last Reset ............ 323738
Number of Traps Since Log Last Displayed .... 0
Log System Time              Trap
0 Mon Mar 11 08:21:49 2013 Client with MAC address 00:24:d6:3c:20:20 has joi
                             ned profile SC Wireless
1 Mon Mar 11 08:20:16 2013 Client with MAC address 00:24:d6:3c:20:20 has joi
                             ned profile SC Wireless
2 Mon Mar 11 08:19:09 2013 Client with MAC address 00:24:d6:3c:20:20 has joi
                             ned profile SC Wireless
3 Mon Mar 11 08:10:21 2013 Client with MAC address cc:af:78:44:7d:2b has joi
                             ned profile SC Wireless
4 Mon Mar 11 08:10:18 2013 Client with MAC address cc:af:78:44:7d:2b has joi
                             ned profile SC Wireless
Keep in mind that I have all trap controls disabled.
(Cisco Controller) >show trapflags
Authentication Flag.............................. Disable
Link Up/Down Flag................................ Disable
Multiple Users Flag.............................. Disable
configsave....................................... Disabled
strong-pwd check................................. Disabled
Client Related Traps
        802.11 Disassociation........................... Disabled
        802.11 Association.............................. Disabled
        802.11 Deauthenticate........................... Disabled
        802.11 Authenticate Failure..................... Disabled
        802.11 Association Failure...................... Disabled
        Excluded........................................ Disabled
        Authentication.................................. Disabled
Cisco AP
        AuthFailure..................................... Disabled
        Register........................................ Disabled
        InterfaceUp..................................... Disabled
802.11 Security related traps
        WEP/WPA Decrypt Error........................... Disabled
        IDS Signature Attack............................ Disable
AAA
        auth............................................ Disabled
        servers......................................... Disabled
rogueap......................................... Disabled
Auto-RF Profiles
        Load............................................ Disabled
        Noise........................................... Disabled
        Interference.................................... Disabled
        Coverage........................................ Disabled
Auto-RF Thresholds
        tx-power........................................ Disabled
        channel......................................... Disabled
Mesh
        auth failure.................................... Disabled
        child excluded parent........................... Disabled
        parent change................................... Disabled
        child moved..................................... Disabled
        excessive parent change......................... Disabled
        onset SNR....................................... Disabled
        abate SNR....................................... Disabled
        console login................................... Disabled
        excessive association........................... Disabled
        default bridge group name....................... Disabled
        excessive hop count............................. Disabled
        excessive children.............................. Disabled
        sec backhaul change............................. Disabled
Hopefully I'm just missing something stupid, but it appears all flags are off.
Message was edited by: Casey Hearn
Added "Show TrapFlags" details.

Message: Port 'Serial0/0/0:9-Bearer Channel' is down on device

Hi guys ;
I got this message on my Cisco Prime from a remote 2911 router, the office is running fine, phone system is working. I got alerts like every 15 min the goes down and up.The message is via email.
Message: Port 'Serial0/0/0:9-Bearer Channel' is down on device
any toughts thanks

Hi Juan,
I also face the same issue on my switch port. What TAC Engineer advice me is to :
1- configure "no snmp trap link-status" on the interface
2- re-sync the device.
Regards,
Syafiq

What is the minimum server layer OEM version supports SNMP trap reception ?

Hi:
- I have been trying to enable SNMP trap reception on an OEM plug-in.
- I turned on debug channel for recvlets.snmp and saw:
2009-10-16 16:07:42,808 Thread-3028552624 ERROR recvlets.snmp: Duplicate threshold : test900, oracle_guide, interfaces, status
and
2009-10-16 16:09:08,382 Thread-3021634480 INFO recvlets.snmp: Trap received is to convert Data Point
2009-10-16 16:09:08,379 Thread-3021634480 INFO recvlets.snmp: Sending Data Point ...
2009-10-16 16:09:08,379 Thread-3021634480 INFO recvlets.snmp: Listening for TRAP
So, it looks like the OEM agent can receive traps but no data point or alert appears.
And, the agent always issues an error about duplicate thresholds.
- Does the agent have to be patched ?
My agent is:
Oracle Enterprise Manager 10g Release 5 Grid Control 10.2.0.5.0.
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
Agent Version : 10.2.0.5.0
OMS Version : 10.2.0.1.0
Protocol Version : 10.2.0.0.0
Agent is Running and Ready
- on the server layer, the oms is:
Oracle Enterprise Manager 10g Release 10.2.0.1.0
Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved.
Oracle Management Server is Up.
Is a patch needed for OMS ?
Should OMS be version 10.2.0.5.0 ?
Thanks
John
Edited by: user8826739 on Feb 23, 2010 7:17 AM

10.2.0.5 should be fine ...
Dave

SNMP Traps is not being sent clear event when DB is UP

Test Traps everything else is also coming fine. Listener, Database Errors, down etc are all coming in fine thru' SNMP. SNMP traps and OEM all working ok. Question is for database up event there is no CLEAR event being sent. Is there anything else that needs to be configured?
SQL> SELECT owner, name, enqueue_enabled, dequeue_enabled FROM dba_queues
2 WHERE name like '%NOTIFY%';
OWNER NAME ENQUEUE DEQUEUE
SYS AQ_PROP_NOTIFY YES YES
SYSMAN AQ$_MGMT_NOTIFY_QTABLE_E NO NO
SYSMAN MGMT_NOTIFY_Q YES YES
SYSMAN AQ$_MGMT_NOTIFY_INPUT_QTABLE_E NO NO
SYSMAN MGMT_NOTIFY_INPUT_Q YES YES

Hello,
Under interface for specific interface: snmp trap link-status
http://www.cisco.com/en/US/docs/ios/12_0/configfun/command/reference/frmonitr.html#wp1023375
Also in newer IOS
The snmp-server enable traps snmp [ linkup] [linkdown] form of this command replaces the snmp trap link-status interface configuration mode command.
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094a05.shtml
HTH
Saju
Pls rate helpful posts

Prime Infrastructure 2.1 - Fan-Failure SNMP-Trap Issue

Hello,
I am facing the following Prime Infrastructure (v2.1) issue:
- A Fan-Failure SNMP-Trap from a Cisco 3650 switch doesn't appear on Prime, but a Link-Failure from the same switch does.
- The both events appears on Prime with Syslog.
- The command "snmp-server enable traps envmon fan shutdown supply temperature status" is set up.
- The switch is in "Managed" state in PI, I have checked the ACL at the "snmp-server community" command, it is okay.
- I have set up an SNMP-Trace for the switch on PI, but only "SNMP Null was returned for class com.cisco.server.managedobjects.bridge.Fan3KStats attribute fanIndex" arrived. Please find the log below.
07/02/14 12:39:53.211 TRACE [presence-9] [] Adding attributes for object Fan3KStats[151206060_,1012]
07/02/14 12:39:53.211 TRACE [presence-9] [] Index name : fanIndex
07/02/14 12:39:53.211 TRACE [presence-9] [] Index Value : 1012
07/02/14 12:39:53.211 TRACE [presence-9] [] Device MIB table index: .1012
07/02/14 12:39:53.211 TRACE [presence-9] [] MIB table row index: .1012
07/02/14 12:39:53.211 TRACE [presence-9] []     OID for : fanIndex = 1.3.6.1.2.1.47.1.1.1.1.1.1012
07/02/14 12:39:53.211 TRACE [presence-9] []     OID for : fanOperStatus = 1.3.6.1.4.1.9.9.13.1.4.1.3.1012
07/02/14 12:39:53.211 TRACE [presence-9] [] Get fragment
07/02/14 12:39:53.211 TRACE [presence-9] [] Creating PDU: Get
07/02/14 12:39:53.211 TRACE [presence-9] []     VarBind OID=1.3.6.1.2.1.47.1.1.1.1.1.1010
07/02/14 12:39:53.211 TRACE [presence-9] []     VarBind OID=1.3.6.1.4.1.9.9.13.1.4.1.3.1010
07/02/14 12:39:53.211 TRACE [presence-9] []     VarBind OID=1.3.6.1.2.1.47.1.1.1.1.1.1011
07/02/14 12:39:53.211 TRACE [presence-9] []     VarBind OID=1.3.6.1.4.1.9.9.13.1.4.1.3.1011
07/02/14 12:39:53.211 TRACE [presence-9] []     VarBind OID=1.3.6.1.2.1.47.1.1.1.1.1.1012
07/02/14 12:39:53.211 TRACE [presence-9] []     VarBind OID=1.3.6.1.4.1.9.9.13.1.4.1.3.1012
07/02/14 12:39:53.218 TRACE [presence-9] [] Error Status: 0
07/02/14 12:39:53.218 TRACE [presence-9] [] Error index: 0
07/02/14 12:39:53.218 TRACE [presence-9] [] SNMP Null was returned for class com.cisco.server.managedobjects.bridge.Fan3KStats attribute fanIndex
07/02/14 12:39:53.218 TRACE [presence-9] []     Setting attribute: fanOperStatus
07/02/14 12:39:53.218 TRACE [presence-9] []     SnmpInt Value : ?
07/02/14 12:39:53.218 TRACE [presence-9] [] GetMultiAttributes, storing result, class=com.cisco.server.managedobjects.bridge.Fan3KStats, attr=fanOperStatus
07/02/14 12:39:53.218 TRACE [presence-9] [] SNMP Null was returned for class com.cisco.server.managedobjects.bridge.Fan3KStats attribute fanIndex
07/02/14 12:39:53.218 TRACE [presence-9] []     Setting attribute: fanOperStatus
07/02/14 12:39:53.218 TRACE [presence-9] []     SnmpInt Value : ?
07/02/14 12:39:53.218 TRACE [presence-9] [] GetMultiAttributes, storing result, class=com.cisco.server.managedobjects.bridge.Fan3KStats, attr=fanOperStatus
07/02/14 12:39:53.218 TRACE [presence-9] [] SNMP Null was returned for class com.cisco.server.managedobjects.bridge.Fan3KStats attribute fanIndex
07/02/14 12:39:53.218 TRACE [presence-9] []     Setting attribute: fanOperStatus
07/02/14 12:39:53.218 TRACE [presence-9] []     SnmpInt Value : ?
07/02/14 12:39:53.218 TRACE [presence-9] [] GetMultiAttributes, storing result, class=com.cisco.server.managedobjects.bridge.Fan3KStats, attr=fanOperStatus
07/02/14 12:39:53.218 TRACE [presence-9] [] GetMultiAttributes, assembling attributes
07/02/14 12:39:53.218 TRACE [presence-9] []     MIB lookup, OID for: powerSupplyIndex = 1.3.6.1.2.1.47.1.1.1.1.1
07/02/14 12:39:53.218 TRACE [presence-9] []     GetMultiAttributes needs class=com.cisco.server.managedobjects.bridge.PowerSupply3kStats, field=powerSupplyIndex
07/02/14 12:39:53.218 TRACE [presence-9] []     MIB lookup, OID for: powerSupplyOperStatus = 1.3.6.1.4.1.9.9.13.1.5.1.3
07/02/14 12:39:53.218 TRACE [presence-9] []     GetMultiAttributes needs class=com.cisco.server.managedobjects.bridge.PowerSupply3kStats, field=powerSupplyOperStatus
07/02/14 12:39:53.218 TRACE [presence-9] [] GetMultiAttributes invoked
07/02/14 12:39:53.218 TRACE [presence-9] [] GetMultiAttributes building OIDs for next PDU
07/02/14 12:39:53.218 TRACE [presence-9] [] Adding attributes for object PowerSupply3kStats[151206060_,1009]
- The switch sends the SNMP Trap, based on the followings:
Jul 7 13:38:30 UTC: SNMP: Packet sent via UDP to IP_ADDRESS
Jul 7 13:38:30 UTC: %PLATFORM_THERMAL-6-FRU_FAN_OIR: Switch 1: System fan 1 removed
Jul 7 13:38:30 UTC: %PLATFORM_THERMAL-1-FRU_FAN_NOT_PRESENT: Switch 1: System fan 1 not present
Jul 7 13:38:30 UTC: SNMP: Queuing packet to IP_ADDRESS
Jul 7 13:38:30 UTC: SNMP: V2 Trap, reqid 33202, errstat 0, erridx 0
sysUpTime.0 = 576753333
snmpTrapOID.0 = ciscoEnvMonMIBNotifications.8
ciscoEnvMonFanStatusEntry.2.1010 = Switch 1 - FAN 1, NotExist
ciscoEnvMonFanStatusEntry.3.1010 = 5
Jul 7 13:38:30 UTC: SNMP: Queuing packet to IP_ADDRESS
Jul 7 13:38:30 UTC: SNMP: V2 Trap, reqid 33203, errstat 0, erridx 0
sysUpTime.0 = 576753333
snmpTrapOID.0 = ciscoEnvMonMIBNotifications.8
ciscoEnvMonFanStatusEntry.2.1010 = Switch 1 - FAN 1, NotExist
ciscoEnvMonFanStatusEntry.3.1010 = 5
Jul 7 13:38:30 UTC: SNMP: Queuing packet to IP_ADDRESS
Jul 7 13:38:30 UTC: SNMP: V2 Trap, reqid 33204, errstat 0, erridx 0
sysUpTime.0 = 576753333
snmpTrapOID.0 = ciscoEnvMonMIBNotifications.8
ciscoEnvMonFanStatusEntry.2.1010 = Switch 1 - FAN 1, NotExist
ciscoEnvMonFanStatusEntry.3.1010 = 5
Jul 7 13:38:30 UTC: SNMP: Queuing packet to IP_ADDRESS
Jul 7 13:38:30 UTC: SNMP: V2 Trap, reqid 33205, errstat 0, erridx 0
sysUpTime.0 = 576753333
snmpTrapOID.0 = ciscoEnvMonMIBNotifications.8
ciscoEnvMonFanStatusEntry.2.1010 = Switch 1 - FAN 1, NotExist
ciscoEnvMonFanStatusEntry.3.1010 = 5
Jul 7 13:38:31 UTC: SNMP: Packet sent via UDP to IP_ADDRESS
Jul 7 13:38:31 UTC: SNMP: Packet sent via UDP to IP_ADDRESS
Jul 7 13:38:31 UTC: SNMP: Packet sent via UDP to IP_ADDRESS
Jul 7 13:38:31 UTC: SNMP: Packet sent via UDP to IP_ADDRESS
Jul 7 13:38:45 UTC: SNMP: Packet sent via UDP to IP_ADDRESS
Jul 7 13:38:51 UTC: %PLATFORM_THERMAL-6-FRU_FAN_OIR: Switch 1: System fan 1 inserted
Jul 7 13:38:54 UTC: SNMP: Queuing packet to IP_ADDRESS
Jul 7 13:38:54 UTC: SNMP: V2 Trap, reqid 33206, errstat 0, erridx 0
sysUpTime.0 = 576755733
snmpTrapOID.0 = ciscoEnvMonMIBNotifications.8
ciscoEnvMonFanStatusEntry.2.1010 = Switch 1 - FAN 1, Normal
ciscoEnvMonFanStatusEntry.3.1010 = 1
Jul 7 13:38:54 UTC: SNMP: Queuing packet to IP_ADDRESS
Jul 7 13:38:54 UTC: SNMP: V2 Trap, reqid 33207, errstat 0, erridx 0
sysUpTime.0 = 576755733
snmpTrapOID.0 = ciscoEnvMonMIBNotifications.8
ciscoEnvMonFanStatusEntry.2.1010 = Switch 1 - FAN 1, Normal
ciscoEnvMonFanStatusEntry.3.1010 = 1
Jul 7 13:38:54 UTC: SNMP: Queuing packet to IP_ADDRESS
Jul 7 13:38:54 UTC: SNMP: V2 Trap, reqid 33208, errstat 0, erridx 0
sysUpTime.0 = 576755733
snmpTrapOID.0 = ciscoEnvMonMIBNotifications.8
ciscoEnvMonFanStatusEntry.2.1010 = Switch 1 - FAN 1, Normal
ciscoEnvMonFanStatusEntry.3.1010 = 1
Jul 7 13:38:54 UTC: SNMP: Queuing packet to IP_ADDRESS
Jul 7 13:38:54 UTC: SNMP: V2 Trap, reqid 33209, errstat 0, erridx 0
sysUpTime.0 = 576755733
snmpTrapOID.0 = ciscoEnvMonMIBNotifications.8
ciscoEnvMonFanStatusEntry.2.1010 = Switch 1 - FAN 1, Normal
ciscoEnvMonFanStatusEntry.3.1010 = 1
Jul 7 13:38:55 UTC: SNMP: Packet sent via UDP to IP_ADDRESS
Jul 7 13:38:55 UTC: SNMP: Packet sent via UDP to IP_ADDRESS
Jul 7 13:38:55 UTC: SNMP: Packet sent via UDP to IP_ADDRESS
Jul 7 13:38:55 UTC: SNMP: Packet sent via UDP to IP_ADDRESS
It seems like PI and the switch doesn't understand each other concerning the fan...
Thanks for any ideas, comments and feedbacks,
Csaba

I have the very same problem.
The switch has a power supply error (one of the two is down). There is the syslog message in PI about it, but no event has created, so nor alarm is there as well.
When I check the status of the switch in the Device Work Center, and choose the Environment in Device Details I can see that PI has not realized the power supply error.
However when I click on the Sync for this very device the power supply status is updated, but still no event or alarm.
This is the case with the FANs as well.

Phantom SNMP Traps

Hi,
I've got most of my devices spouting SNMP traps for various different things, and Ciscoworks forwards these traps on via email, as you do.
For most things it works great, however since we've created a script to pull on the configs off the devices (Simply don't trust Ciscoworks), we're always spammed with SNMP traps like the one below:
ALERT ID                = 000071P
TIME                    = Mon 10-Jan-2011 16:19:07 GMT
STATUS                  = Active
SEVERITY                = Critical
MANAGED OBJECT          = lrouter-loo-0.mwam.local
MANAGED OBJECT TYPE     = Switches and Hubs
EVENT DESCRIPTION       = router1-loo-0.mwam.local: Cisco Configuration Management Trap:InformAlarm; PORT-lon-cr1-loo-0.mwam.local/10113 [Gi1/0/13] [Trunk to router2-gig-1-0-24]:OperationallyDown;
CUSTOMER IDENTIFICATION = networks-info
I know one port is down, and that's expected, I just haven't cleared the alert and turned off the monitoring in DFM.
We're using:
snmp-server enable traps config-copy
snmp-server enable traps config
on all of our devices, but only 4 out of 80+ devices throw this trap out when their config is copied by the script.
I've googled extensively, but I haven't come across any real help.
Has anyone got any idea what the situation is with this? I'm getting bored of deleting a bunch of emails every time our script runs, and I don't want to create a rule for fear of filtering real alerts.
Any ideas would be appreciated
Cheers

This isn't a trap. This is a DFM alert, which consists of multiple atomic events. In this case, it looks like the alert consists of two events. The first is a CISCO-CONFIG-MAN-MIB trap (i.e. ciscoConfigManEvent). If you look at the associated event in the DFM Alerts and Acitivities Display, I'll bet it will indicate the configuration was copied (per your script). The other event indicates that port Gi1/0/13 is operationally down on this switch. The two events are unrelated, but apply to the same device.

Anyone have succes configuring SNMP traps?

anyone have succes testing SNMP with snmptrap command?
Hello,
I am new to Ironport and the setup configuration of these devices. I am in the process of testing the snmp feature of these servers. As such I have configured the SNMP via snmpconfig command. From customer support I tried to enter the process for alerts and have not been able to get anything. https://ironport.custhelp.com/cgi-bin/ironport.cfg/php/enduser/std_adp.php?p_faqid=949&p_li=cF91c2VyaWQ9MXJvblAwcnQmcF9wYXNzd2Q9Zm8wQmE1
Is the link to process. I suspect that the traps are not being sent from the appliance. I have gone over the Doc for the configuration and can't see any errors. I have AsyncOS 6.4 for IronPort M660. This is the Admin server for a C150 and C350. Of which I can get no snmp traps either. The snmp manager is CA if that helps. Is there a log file on Ironport to verify taht traps have been sent? I see my command in the CLI log file.

The main issue is not being able to send a snmp trap to a CA NSM agent. Anyone been down this road before????

Cisco Prime SNMP Traps Best Pratice

The Cisco Prime documentation recommends configuring switches to send SNMP traps. However it does not give any more details.
I was wondering what sorts of SNMP traps people in the community are using with Cisco Prime 2.1. I'm looking for some sort of best practice or for an idea of what traps would be the most useful to configure on the switches, to send to Prime.

Hi ,
Snmp traps need to be configured only on device end , there is no config need to be done on PI.
you can enable all the traps that you want. for e.g
snmp-server enable traps syslog
snmp-server enable traps ipsec start stop
snmp-server enable traps memory-threshold
snmp-server enable traps interface-threshold
snmp-server enable traps connection-limit-reached
snmp-server enable traps cpu threshold rising
etc......
and you can monitor then in PI (Administration > System Settings > Severity Configuration, Link down)
check the below link as well:
https://supportforums.cisco.com/discussion/11919481/prime-infrastructure-20-link-status-alarms
Thanks-
Afroz
***Ratings Encourages Contributors ***

SNMP Traps by Nexus 5010

I (my customer) does not get SNMP Traps from the N5k when he unplugs one power supply (only logs). He gets only traps when he turns both power supplies off. If I check show snmp trap all trap entity are enabled (rmon Trap are off). NX-OS is 4.2(1)N2(1).
How he will get traps if one power supplies is off or fails?

Hi
Thanks for your support.
First I like to mention that the issue is when an Nexus2k behind the 5k (FEX) looses the power on one power-supply.
The trap I get if both power supplies are disconected is:
"Power Status Change Event.
The power operational status of a FRAU at entPhysicalTable index has changed to offEnvPower.
Power Admin Status: . "
4 seconds later I get than also the FRU Removal Event.
like mentioned eralier we also would like to get snmp traps when only one power supply goes down, but can't not figure out the config for that.
K.R.
Markus

Throttle SNMP traps

What is the best way to throttle snmp traps? I have an HP NNM (Network Node Manger) server that is currently receiving traps from a number of network devices. Sometimes traps get sent from these devices at a higher rate than the NNM server can handle. When this happens the NNM server is basically so overwhelmed it gets hung.
I have a Cisco 1811 ISR that is acting as my remote tunnel device. The monitored devices (switches, firewalls, routers, etc.) are on the local LAN behind the ISR and all monitoring traffic is sent to the NNM server through the IPSec tunnel.
Is there a way to either batch process snmp traps or throttle/cap the rate that the messages get sent? I would prefer to do this somehow on the ISR as it will keep the number of configurations I have to do way down.
Thanks,
-mike

Luckily you have NNM. As long as you're running NNM 6.4 or later (up to 7.53 that I can testify for), you can configure throttling there. Instead of rehashing it, I point to the post by Prashant over at HP ITRC:
http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1289854149785+28353475&threadId=1011198
Note that I don't personally adopt Step 3 in Prashant's post, of blocking individual offending IP addrs specifically in ovtrapd.conf. Without that step, I simply configure ovtrapd.lrf to give whichever IP addr that crosses the "-B -r ##" threshold a temporary "time out". Once that offender's trap rate drops below the configured threshold, NNM unblocks it, until the next violation.
This is not a perfect "throttle", because all traps (interesting ones and noises) from the offending IP are tuned out during the blockade.

SNMP trapping PRI channels up/down

Similar Messages

Maybe you are looking for