Manipulating SNMP Trap link_down severity level?

Dear Cisco experts,
I wonder if there's a way to manipulate sent traps from a switch with different severity levels?
I now see SNMP link_down traps in my NMS, but they're all of the same level, but a link_down from a desktop is 'normal', a server link_down would be 'warning', but when an uplink to another data center goes down, it should result in all alarms going off, so should be 'critical'.
Is there a way to tell my switch to send an SNMP trap on a different severity level dependent on the type of interface? This is most important because these links all have different SLAs.
Many thanks for your support and suggestions.
Marco van der Pal

This is not possible, Only one sort of trap is possible
You best approach woud be to disable up-down traps on ports that are not important.
LMS now has port groups. That feature could be usefull for doing this
Cheers,
Michel

Similar Messages

SNMP trap on OutOfMemory Error Log record

I would like to implement SNMP trap on OutOfMemory Error Log record.
In theory SNMP LogFilter with Severity Level "Error" and Message Substring "OutOfMemory" should do the trick.
In reality it does not work (doh)(see explanations below), I wonder if someone managed to make it work.
Log entry has following format:
----------- entry begin ----------
####<Nov 12, 2003 3:09:23 PM EST> <Error> <HTTP> <ustrwd2021> <local> <ExecuteThread: '14' for queue: 'default'> <> <> <101020> <[WebAppServletContext(747136,logs2,/logs2)] Servlet failed with Exception>
java.lang.OutOfMemoryError
<<no stack trace available>>
------------ entry end ------------
Notice that java.lang.... is NOT part of the log record, yep it seems that exception stack trace is not part of log record! Thus filter could be applied only to "<[WebAppServletContext(747136,logs2,/logs2)] Servlet failed with Exception>" string, which is really useless.
Here is fragment of trap data (i had to remove Message Substring in order to get Error trap to work)
1.3.6.1.4.1.140.625.100.50: trapLogMessage: [WebAppServletContext(747136,logs2,/logs2)] Servlet failed with Exception

Andriy,
I dont think you could do much here, since Outofmemory is not part of
log record SNMP agent cannot filter on this. I would be curious to hear
if anyone got it to work using SNMP.
sorry,
-satya
Andriy Potapov wrote:
I would like to implement SNMP trap on OutOfMemory Error Log record.
In theory SNMP LogFilter with Severity Level "Error" and Message Substring "OutOfMemory" should do the trick.
In reality it does not work (doh)(see explanations below), I wonder if someone managed to make it work.
Log entry has following format:
----------- entry begin ----------
####<Nov 12, 2003 3:09:23 PM EST> <Error> <HTTP> <ustrwd2021> <local> <ExecuteThread: '14' for queue: 'default'> <> <> <101020> <[WebAppServletContext(747136,logs2,/logs2)] Servlet failed with Exception>
java.lang.OutOfMemoryError
<<no stack trace available>>
------------ entry end ------------
Notice that java.lang.... is NOT part of the log record, yep it seems that exception stack trace is not part of log record! Thus filter could be applied only to "<[WebAppServletContext(747136,logs2,/logs2)] Servlet failed with Exception>" string, which is really useless.
Here is fragment of trap data (i had to remove Message Substring in order to get Error trap to work)
1.3.6.1.4.1.140.625.100.50: trapLogMessage: [WebAppServletContext(747136,logs2,/logs2)] Servlet failed with Exception

I can not make IP SLA to signal SNMP traps upon timeout

Hello team.
I want SNMP traps to be sent every time an IP SLA (ICMP) object times out. For that purpose, I carried out the following
ip sla monitor logging traps
ip sla monitor 1
type echo protocol ipIcmpEcho 10.1.1.254
timeout 1000
frequency 15
ip sla monitor schedule 1 life forever start-time now
snmp-server enable traps rtr
snmp-server host 10.1.1.10 mycommunity
But no SNMP trap is sent when the IP SLA object times out. ¿ Am I missing something?
Any help will be greatly appreciated.
Rogelio Alvez
Argentina

SNMP traps for IP SLAs are handled through the system logging (syslog) process. This means that system logging messages for IP SLAs violations are generated when the specified conditions are met, then sent as SNMP traps using the CISCO-SYSLOG-MIB. The ip sla monitor logging traps command is used to enable the generation of these IP SLAs specific traps. The generation of IP SLAs specific logging messages is dependant on the configuration of the standard set of logging commands (for example, logging on). IP SLAs logging messages are generated at the "informational" system logging severity level.
The command ip sla monitor logging traps is sometime hidden and may not show with ?, so just copy and paste in global config mode and have logging on and check if any traps are generated.
-Thanks
Vinod
**Encourage Contributors. RATE them**

Snmp trap versus syslog message

Hi,
Most network devices will send snmp traps and syslog messages to a central server.
For analyzing purpose this server runs software to display the messages or traps.
My question is, what is the difference between syslog messages and snmp traps?
What is best practise?
Thank you very much.
Hansruedi

From the very basic level, traps and syslog differ in the encoding. Syslog messages are typically text messages sent within a UDP packet. There is a bit of binary encoding to indicate the syslog facility and severity. SNMP traps have encoded ASN.1 fields (called variable bindings). These varbinds are not ASCII text like syslog messages. Instead they are encoded object identifiers that can be translated into object names using MIB definitions.
More syslog messages exist than SNMP traps because syslog messages do not have as much governance associated with them. However, we typically recommend that customers enable both as there are some details available in traps that you may not get in syslog messages. Traps can also be processed in a more programmatic fashion because of the documentation that goes into the MIBs that define them.

SNMP Trap Translation Wrong For Hebrew Language

SR 3-4956842281
sev 2
Cus ISRAEL CREDIT CARDS LTD
=====================
Customer is using OMS 10.2.0.5 on linux server.
They have created an user defined metric on DB cluster instance with alert message written in hebrew.
The OMS console showed the alert in hebrew as expected.
However when they send this alert with snmp trap notification to a second system (HP openview for windows) then the message appeared not cleared (with question marks). This second system get messages in hebrew from other systems without any problems.
+Does setting LANG variable at OMS level will impact this
+Any tracing which can help to find the cause of the issue

Closing as issue found at HP openview parameter settings

LMS 3.2.1 integration with Clarity NMS for snmp trap forwarding

Our client have integrated Clarity NMS to Ciscoworks LMS 3.2.1. So far they are receiving raw alarms/snmp traps but it lacks information/inventory of the originating device. Kindly see sample raw alarms below:
2420: 2011-11-25 12:10:46 Received trap ==> Received SNMPv1 Trap
Community=ciscoworks
Enterprise=1.3.6.1.6.3.1.1.5
Generip trap type=2
Specific Trap Type=0
Trap From=10.220.10.1
Trap ID=1.3.6.1.6.3.1.1.5.2
Trap Time=-1436283373
1.3.6.1.2.1.2.2.1.1.83=83
1.3.6.1.2.1.2.2.1.2.83=GigabitEthernet1/40
1.3.6.1.2.1.2.2.1.3.83=6
1.3.6.1.4.1.9.2.2.1.1.20.83=Lost Carrier
EndTrap
10933: 2011-11-24 11:57:53 Received trap ==> Received SNMPv1 Trap
Community=ciscoworks
Enterprise=1.3.6.1.4.1.9.1.291
Generip trap type=2
Specific Trap Type=0
Trap From=10.220.10.1
Trap ID=1.3.6.1.4.1.9.1.291.2
Trap Time=1628056965
1.3.6.1.2.1.2.2.1.1.8=8
1.3.6.1.2.1.2.2.1.2.8=E1 0/0/0
1.3.6.1.2.1.2.2.1.3.8=18
EndTrap
As you can see, those raw alarms doesn’t contain any information about the originating equipment or the physical card, port related information where those alarms were generated. Instead those alarms received are just NMS level alarms.
How do we resolve this so that the inventory of the equipment would be part of the trap to be received by Clarity from Ciscoworks.

Hi,
Is the issue you have the source IP address of the forwarded trap? Per RFC it is the IP of the actual device sending the trap. The originating IP should be contained within the packet. I have included some additional information you may find helpful.
Q. What is the difference between SNMP Raw Trap Forwarding and SNMP Trap alert/event Trap Forwarding? Does DFM support both?
A. You can configure raw trap forwarding at DFM > Other configuration > SNMP Trap forwarding, and processed event/alert trap forwarding at DFM > Notification Services > SNMP Trap Forwarding. Processed trap is "when DFM receives certain SNMP traps, it analyzes the data found in fields (Enterprise/Generic trap identifier/Specific Trap identifier/variable−bindings) of each SNMP trap message, and changes the property value of the object property (if required)". Raw trap is the trap that the device forwards to DFM and DFM has yet to process it. For more information, refer to the DFM User Guide. Yes, DFM supports both ways of trap forwarding.
http://www.cisco.com/en/US/products/sw/cscowork/ps2421/products_qanda_item09186a0080a9b35b.shtml
DFM will only forward SNMP traps from devices in the DFM inventory. It will not change the trap format—it will forward the raw trap in the format in which the trap was received from the device. However, you must enable SNMP on your devices and you must do one of the following:
Configure SNMP to send traps directly to DFM
Integrate SNMP trap receiving with an NMS or a trap daemon
The versions of SNMP traps supported by DFM are described in SNMP and ICMP Polling. For information on forwarding processed and pass-through traps, see Processed and Pass-Through Traps, and Unidentified Traps and Events.
Pass-through traps are traps that DFM receives from devices that are not in the DFM inventory, and DFM has not processed. Forwarding these traps is controlled using Configuration > Other Configurations > SNMP Trap Forwarding. These traps are shown in the Alerts and Activities display because of their relevance to fault monitoring. Pass-through traps are displayed as follows:
As one of the following events:
> InformAlarm
> MinorAlarm
> MajorAlarm
With the device type and the device name from which it was generated.
If DFM does not know which device generated the trap, it ignores the trap. Pass-through traps will be cleared after a default interval of 10 minutes to one hour
http://www.cisco.com/en/US/docs/net_mgmt/ciscoworks_device_fault_manager/3.2/user/guide/dfm32ug_Book.html

Generate SNMP Traps report from LMS database

Hi Experts,
Just wondering how LMS handle all SNMP traps received by LMS? Are the traps keep into a database on the server? Is there a way to extract them out as a report?
Regards,
Yi Shyuan

Hello,
Thank you for your answer, unfortunately this isn't what I was looking for.
My idea was to generate fake-positives traps to test efficiently our NMS station.
Traps that I would like to tests would be Temperature, Fan, Board.
I found that chaning the yellow level of the temp sensor to the lower threshold can provide some start point, but I would like to ensure when a real event arrives that my NMS will react accordingly.
Thanks

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.

Veritas SNMP Traps

Hello to all,
I do not know if this is a right forum to ask this but anyway ...
I know that Solstice Disk suite (native Solaris Volume Manager) is capable of sending SNMP traps towards a SNMP receiver (Sun Net Manager, HP Network Node Manaher ...) upon any problems detected on volume management level.
Can Veritas Volume Manager do the same?

No probs, I have the answer.
It's "config"
int fc2/36
no link-state-trap
Cheers.

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 configuration doesn't work in CUSTOMER-CONTEXT

Hi evryone;
I'm having some issues configurin SNMP traps on a ASA5520 USER-CONTEXT (Cisco Adaptive Security Appliance Software Version 8.2(4)):
I had already configured SNMP traps on ADMIN-CONTEXT and traps were getting the correspondig NETCOOL SERVERS (10.105.27.115 and 10.105.27.118) as you can see in point 2).
Cuold you please give me any clue of why I get this output for a non ADMIN-CONTEXT and why I do not even see SNMP packets output
1) CUST-09-CONTEXT
name 10.105.27.115 Netcool1_TESTBED description Netcool1_TESTBED SNMP server.
name 10.105.27.118 Netcool2_TESTBED description Netcool2_TESTBED SNMP server.
snmp-server community sjnemdhqksptabld
snmp-server host CUST-09-HCS-MNGT-TRANSIT Netcool1_TESTBED community sjnemdhqksptabld version 2c
snmp-server host CUST-09-HCS-MNGT-TRANSIT Netcool2_TESTBED community sjnemdhqksptabld version 2c
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
snmp-server enable traps syslog
route CUST-09-HCS-MNGT-TRANSIT 10.105.27.0 255.255.255.0 192.168.228.1 1
CAPTURES
Lab-asa1-p/CUST-09-CONTEXT/act# capture TEST1 interface CUST-09-HCS-MNGT-TRANSIT match ip host 10.105.27.115 any
Lab-asa1-p/CUST-09-CONTEXT/act# show capture TEST1 trace detail
23 packets captured
   1: 15:17:16.373927 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 9815)
   2: 15:17:18.370433 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 10598)
   3: 15:17:20.370433 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 27648)
   4: 15:17:22.370433 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 3518)
   5: 15:17:24.370433 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 18995)
   6: 15:17:43.015258 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 2110)
   7: 15:17:45.010436 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 11567)
   8: 15:17:47.010436 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 25551)
   9: 15:17:49.010436 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 3716)
10: 15:17:51.010436 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 20820)
11: 15:48:16.998483 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 25423)
12: 15:48:18.990366 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 30357)
13: 15:48:20.990366 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 31174)
14: 15:48:22.990366 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 10878)
15: 15:48:39.735527 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 8146)
16: 15:48:41.730354 1200.0314.0600 0000.0c9f.fc14 0x8100 118: 802.1Q vlan#3092 P0 192.168.228.4 > 10.105.27.115: icmp: echo request (ttl 255, id 1803)
17: 15:49:01.881134 1200.0314.0600 0000.0c9f.fc14 0x8100 46: 802.1Q vlan#3092 P0 192.168.228.4.49175 > 10.105.27.115.33434: [udp sum ok] udp 0 [ttl 1] (id 15279)
18: 15:49:01.881744 1200.0314.0600 0000.0c9f.fc14 0x8100 46: 802.1Q vlan#3092 P0 192.168.228.4.49175 > 10.105.27.115.33435: [udp sum ok] udp 0 [ttl 1] (id 20090)
19: 15:49:01.884201 1200.0314.0600 0000.0c9f.fc14 0x8100 46: 802.1Q vlan#3092 P0 192.168.228.4.49175 > 10.105.27.115.33436: [udp sum ok] udp 0 [ttl 1] (id 24847)
20: 15:49:01.886672 1200.0314.0600 0000.0c9f.fc14 0x8100 46: 802.1Q vlan#3092 P0 192.168.228.4.49175 > 10.105.27.115.33437: [udp sum ok] udp 0 (ttl 2, id 8822)
21: 15:49:04.880356 1200.0314.0600 0000.0c9f.fc14 0x8100 46: 802.1Q vlan#3092 P0 192.168.228.4.49175 > 10.105.27.115.33438: [udp sum ok] udp 0 (ttl 2, id 20949)
22: 15:49:07.880371 1200.0314.0600 0000.0c9f.fc14 0x8100 46: 802.1Q vlan#3092 P0 192.168.228.4.49175 > 10.105.27.115.33439: [udp sum ok] udp 0 (ttl 2, id 9126)
23: 15:49:10.880340 1200.0314.0600 0000.0c9f.fc14 0x8100 46: 802.1Q vlan#3092 P0 192.168.228.4.49175 > 10.105.27.115.33440: [udp sum ok] udp 0 (ttl 3, id 24404)
23 packets shown
I had already configured SNMP traps on ADMIN-CONTEXT and traps were getting the correspondig NETCOOL SERVERS:
2) CONFIGURATION ADMIN-CONTEXT
IP Management ASA-FW -->10.105.89.38
interface GigabitEthernet0/3.710
nameif management
security-level 100
ip address 10.105.89.38 255.255.255.192 standby 10.105.89.39
management-only
name 10.105.27.115 Netcool1_TESTBED description Netcool1_TESTBED SNMP server.
name 10.105.27.118 Netcool2_TESTBED description Netcool2_TESTBED SNMP server.
snmp-server community sjnemdhqksptabld
snmp-server host management Netcool1_TESTBED community sjnemdhqksptabld version 2c
snmp-server host management Netcool2_TESTBED community sjnemdhqksptabld version 2c
snmp-server enable traps snmp authentication linkup linkdown coldstart
snmp-server enable traps syslog
ip route 0.0.0.0 0.0.0.0 10.105.89.1
CAPTURES : I could see 206 SNMP packets output and traffic towards the NETCOOL SERVERS (10.105.27.115 AND 10.105.27.118)
Lab-asa1-p/ADMIN-CONTEXT/act# sh snmp statistics
0 SNMP packets input
    0 Bad SNMP version errors
    0 Unknown community name
    0 Illegal operation for community name supplied
    0 Encoding errors
    0 Number of requested variables
    0 Number of altered variables
    0 Get-request PDUs
    0 Get-next PDUs
    0 Get-bulk PDUs
    0 Set-request PDUs (Not supported)
206 SNMP packets output
    0 Too big errors (Maximum packet size 512)
    0 No such name errors
    0 Bad values errors
    0 General errors
    0 Response PDUs
    206 Trap PDUs
Lab-asa1-p/ADMIN-CONTEXT/act#
Lab-asa1-p/ADMIN-CONTEXT/act# capture TEST1 interface management match ip host 10.105.27.115 any
Lab-asa1-p/ADMIN-CONTEXT/act# show capture TEST1
5 packets captured
   1: 18:36:17.631070 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.115.162: udp 356
   2: 18:36:18.491261 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.115.162: udp 355
   3: 18:36:22.389338 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.115.162: udp 266
   4: 18:36:29.491231 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.115.162: udp 355
   5: 18:36:40.491246 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.115.162: udp 355
5 packets shown
Lab-asa1-p/ADMIN-CONTEXT/act# capture TEST2 interface management match ip host 10.105.27.118 any
Lab-asa1-p/ADMIN-CONTEXT/act# show capture TEST2
13 packets captured
   1: 18:37:16.198094 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 356
   2: 18:37:24.491307 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
   3: 18:37:35.491307 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
   4: 18:37:46.491307 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
   5: 18:37:57.491307 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
   6: 18:38:08.491322 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
   7: 18:38:19.491292 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
   8: 18:38:30.491338 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
   9: 18:38:41.491307 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
10: 18:38:52.491307 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
11: 18:39:03.491307 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
12: 18:39:14.491307 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
13: 18:39:25.491307 802.1Q vlan#710 P0 10.105.89.38.162 > 10.105.27.118.162: udp 355
13 packets shown
thanks
Ana

Hi guys coould you please help me out ??
BR
ANA

Re:SNMP Trap in 10.3

Hello
We are migrating Applications for 8.1 to 10.3
So we wanted to set SNMP Traps in the 10.3 at the domain Level
We had setup the traps in 10.3 and restarted but we are not able to recevie any traps
Please let me know if you have any suggestions
Regards
-nar-

When you start the managed server, you should see a message such as the following:
<Feb 18, 2010 12:39:04 AM EST> <Notice> <SNMP> <BEA-320931> <The SNMP trap version is 2>
Are you using a port > 1000 on your Server agent? 161 is probably just your port on the Domain agent. There are 2 ports to be careful of, SNMP UDP Port and Master AgentX Port; both on the General tab for the server agent.
Here's an extract of the SNMP config, showing the "Server SNMP Agents" and a single String Monitor for the server status
<snmp-agent-deployment>
<name>Name_of_server_SNMPAgent</name>
<enabled>true</enabled>
<send-automatic-traps-enabled>true</send-automatic-traps-enabled>
<snmp-port>1161</snmp-port>
<snmp-trap-version>2</snmp-trap-version>
<community-prefix>public</community-prefix>
<snmp-trap-destination>
<name>some name</name>
<host>xxx.xxx.xxx.xxx</host>
<port>162</port>
<community>public</community>
<security-level>noAuthNoPriv</security-level>
</snmp-trap-destination>
<snmp-string-monitor>
<name>ServerStatus</name>
<enabled-server>Server1,Server2</enabled-server>
<monitored-m-bean-type>ServerRuntime</monitored-m-bean-type>
<monitored-m-bean-name></monitored-m-bean-name>
<monitored-attribute-name>HealthState</monitored-attribute-name>
<polling-interval>10</polling-interval>
<string-to-compare>OK</string-to-compare>
<notify-differ>true</notify-differ>
<notify-match>false</notify-match>
</snmp-string-monitor>
<community-based-access-enabled>true</community-based-access-enabled>
<snmp-engine-id>Name_of_server_SNMPAgent</snmp-engine-id>
<authentication-protocol>noAuth</authentication-protocol>
<privacy-protocol>noPriv</privacy-protocol>
<inform-retry-interval>10000</inform-retry-interval>
<max-inform-retry-count>1</max-inform-retry-count>
<localized-key-cache-invalidation-interval>3600000</localized-key-cache-invalidation-interval>
<snmp-access-for-user-m-beans-enabled>false</snmp-access-for-user-m-beans-enabled>
<inform-enabled>false</inform-enabled>
<master-agent-x-port>1705</master-agent-x-port>
<target>AdminServer,Cluster1,Cluster2</target>
</snmp-agent-deployment>

Different Source Address for a SNMP trap paquet

We use a common platform to manage the CISCO routers for several customers. We are using to manage the devices w/ a loopback address as source of snmp paquet.
We use something like this ...
Router(config)#snmp-server host 172.25.1.1 ORATRAP
Router(config)#snmp-server trap-source loopback0
Router(config)#end
Now, there is some customers that request us to receipt the snmp-traps w/ an ip source of their own ip space (192.168.2.x/24).I cannot imagine how this can be achieve?... Please any idea?. Thks. Eduard.

Thks., for your help. This is important matter to us. We also working in the idea of snmp track collector close to our own NMC... but this may cost also money... . So, we are going to try another approach first..
Somewhat like this below....
snmp-server enable traps
snmp-server informs
snmp-server source-interface traps
snmp-server source-interface informs
snmp-server host traps version 1 community string publicCust
snmp-server host informs version 2 community string publicBT
For the get's every MNC sends to the declared IP, so We thing that will use the same IP in answer.
I will let you know. Eduard.

Odd SNMP trap - anyone else seen this?

Hi, all!
Just got and implemented a couple of C300s and they're making my life a lot easier than my old Marshal servers, but I'm seeing an odd alert in my SNMP traps that doesn't appear to be getting translated by the MIB, and since my traps generate emails to me unless it's a critical, it's leading to something like 125 emails a night.
Just wondering if anyone had seen this trap before and could tell me A) What the hell it is (I -think- it might be related to definition updates or quarantined messages, but I can't find anything to prove that) and B) If it's not in the MIB, if anyone else wrote a custom MIB entry to cover it so I can get some better reporting.
NodeName=(appliance)
Application=SNMPTraps
Severity=16
Tally=1
MessageText=Virus Outbreak Filters
NodePlatform=other
NodeOperatingSystem=other
MessageNumber=22562b36-5453-71dc-1ce3-0a69c6460000
MessageGroup=ACM
Object=(UNAVAILABLE EVENT PARAMETER $2)
Source=Ironport
TimeCreated=8/27/2007 00:08:15
TimeReceived=8/27/2007 00:08:15
TimeLastReceived=8/27/2007 11:28:19
Thanks!

The message above should be comming from the traps that we translate into messages
SNMPTraps-IronPort Update failure for (Sophos Antivirus)
SNMPTraps-IronPort Update failure for (Virus Outbreak Filters)
SNMPTraps-IronPort Update failure for (IronPort Anti-Spam)
Where original traps are these below, and meaning should be that attempted update from ironport.com failed.
Generic: 6; Specific: 6; Enterprise: .1.3.6.1.4.1.15497.1.1.2.0.6;
Variables:
[1] private.enterprises.IronPort.AsyncOSAppliances.AsyncOSMail.AsyncOSMailObjects.updateTable.updateEntry.updateServiceName (OctetString): Sophos Antivirus
Generic: 6; Specific: 6; Enterprise: .1.3.6.1.4.1.15497.1.1.2.0.6;
Variables:
[1] private.enterprises.ironPort.asyncOSAppliances.asyncOSMail.asyncOSMailObjects.updateTable.updateEntry.updateServiceName (OctetString): Virus Outbreak Filters
Generic: 6; Specific: 6; Enterprise: .1.3.6.1.4.1.15497.1.1.2.0.6;
Variables:
[1] private.enterprises.IronPort.AsyncOSAppliances.AsyncOSMail.AsyncOSMailObjects.updateTable.updateEntry.updateServiceName (OctetString): IronPort Anti-Spam

Syslog traps vs SNMP traps

Concerning the Syslog logging and SNMP traps, what is the difference.
I have seen that syslog is more for troubleshooting, but does syslog, when set to log "debugging", offer the same level of information that SNMP traps do?
For example, can you get real time config changes via syslog as you can with SNMP?
If so, why use both?

syslog will send whatever you can see on the CLI of the device at a maximum of a debug level as you say.
for SNMP traps related to configuration changes, you can use the mibs depending on the events you want to know about.
If we take for example the config traps, they are part of
CISCO-CONFIG-MAN-MIB. That mib can send traps with the following OIDs:
ftp://ftp.cisco.com/pub/mibs/oid/CISCO-CONFIG-MAN-MIB.oid
When you will go through that you will realize that the CONFIG mib and the syslog provide you with the same information: the CONFIG mib will not have more information than the syslog message.
If you use the snmp object navigator, you will find for every OID what the function is:
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en
A good paper about what traps are part of which mib:
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094a05.shtml
SNMP traps are a good way to gather information from the router without spiking the cpu with turning on CLI debug level. The CLI debug level is usually the most complete information you can get from a router anyways.

Manipulating SNMP Trap link_down severity level?

Similar Messages

Maybe you are looking for