Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Ciscoworks IPM and sending SNMP traps

HAs anyone been able to successfully deploy this? I have IPM working fine, I just want to be able to send traps from our source device to our syslog server so we get threshold and Timeout notification. I have TAC case opened so far no success. this is what I have on my 7206

ip sla monitor logging traps

snmp-server community blogblog RO 2

snmp-server community blahblah RW 2

snmp-server enable traps syslog

snmp-server enable traps rtr

snmp-server host 10.24.160.20 blahblah tty config entity envmon syslog rtr snmp

logging trap debugging

logging 10.24.160.20

Here is the doc I am going by;

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hsla_c/hsthresh.htm

26 REPLIES
Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

This is a correct configuration, but traps are not syslog messages. The device will send rtr traps to 10.24.160.20 (provided you have configuration your IP SLA operations to send traps), but if all you have is a syslog server on this host, those traps will be ignored.

Note: DFM does not currently do anything with rtr traps (if you are wanting to use DFM as your trap server). There is a plan to address this as part of the fix for CSCsd03455.

New Member

Re: Ciscoworks IPM and sending SNMP traps

Well that explains it. How or what can I use to recieve these traps? I assume that RME would not work either. So my config is correct and I am sending traps successfully, however my syslog server is not understanding them correct? Any thought when DFM will get this patch?

New Member

Re: Ciscoworks IPM and sending SNMP traps

JUst looked and we are using Kiwi and we do have SNMP traps enabled. Any other thoughts?

Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

As I said in my initial post, you will have to make sure that your operations are configured to send traps. You can look at the show rtr conf output to verify that a given operation should be sending traps. Then you will have to look at the collection stats to make sure you are crossing a threshold that will cause a trap to be sent.

New Member

Re: Ciscoworks IPM and sending SNMP traps

Here is the output of one of the Collectors(270) I have configured. I have a couple of questions;

1) In IPM it shows a rising and falling threshold. In the ip sla configuration it only shows a threshold, not a rising or falling one.

2) I had read in the previously referenced doc, that if you configure a threshold, then the timeout will not be used. A little confused on this.

3) I assume that it will send a trap when it crosses the threshold and will send only one trap when it crosses, not a trap for every poll that it is over the treshold correct?

4) Finally since these are really syslog informational logging messages(level 6), and then are converted to traps using The "ip sla monitor logging traps" command, does this command on my router("logging buffered 1048576 debugging") prevent the logging of informational messages, hence since not logged they won't be converted to traps?

5) As you can see in the last snippet, the treshold has had a failure, however I have not received a trap. I think the problem is the logging. Should I also see something in the router logs as a trap is sent? I am a little concerned about turning on informational logging I don't want to fill up the router.

dr03-clt#sh ip sla monitor configuration 270

IP SLA Monitor, Infrastructure Engine-II.

Entry number: 270

Owner: 17|ipm-pkx66500102-mwitte

Tag: LTL_ECHO_1400

Type of operation to perform: echo

Target address: 10.1.60.18

Source address: 10.24.70.2

Request size (ARR data portion): 1400

Operation timeout (milliseconds): 3000

Type Of Service parameters: 0x0

Verify data: No

Operation frequency (seconds): 30

Next Scheduled Start Time: Start Time already passed

Group Scheduled : FALSE

Life (seconds): Forever

Entry Ageout (seconds): 3600

Recurring (Starting Everyday): FALSE

Status of entry (SNMP RowStatus): Active

Threshold (milliseconds): 89

Number of statistic hours kept: 2

Number of statistic distribution buckets kept: 1

Statistic distribution interval (milliseconds): 20

Number of history Lives kept: 0

Number of history Buckets kept: 15

History Filter Type: None

Enhanced History:

dr03-clt#sh ip sla monitor reaction-configuration 270

Entry number: 270

Reaction: rtt

Threshold Type: Immediate

Rising (milliseconds): 89

Falling (milliseconds): 86

Threshold Count: 5

Threshold Count2: 5

Action Type: Trap only

Reaction: timeout

Threshold Type: Immediate

Threshold Count: 5

Threshold Count2: 5

Action Type: Trap only

dr03-clt#sh ip sla monitor statistics 270 details

Round trip time (RTT) Index 270

Latest RTT: 88 ms

Latest operation start time: 09:23:27.158 EST Mon Nov 27 2006

Latest operation return code: OK

Over thresholds occurred: FALSE

Number of successes: 24

Number of failures: 2

Operation time to live: Forever

Operational state of entry: Active

Last time this entry was reset: Never

Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

1. The rising and falling thresholds are there under your reaction configuration.

2. I don't see in this document where it mentions that.

3. Correct. It will not send another trap until the threshold crosses the falling line and re-arms itself.

4. No. However, you don't need to use syslog traps for this operation. This is an echo operation, and it will send traps using the CISCO-RTTMON-MIB. The CISCO-SYSLOG-MIB is only needed for voice-related operations.

5. You should have received two traps relating to the failures. Are you receiving any other traps on your Kiwi server from this router? What does "show snmp" report on the router? What traps have you received on your Kiwi server from this device?

New Member

Re: Ciscoworks IPM and sending SNMP traps

Also one thing I saw is that we are using the

"logging 10.24.160.20" command

instead of

"logging host 10.24.160.20" command

What is the difference if any??

Re: Ciscoworks IPM and sending SNMP traps

the only difference are different IOS versions, so these are only syntactical differences not functional..

But as joe asked, do you see any traps on the kiwi trap receiver originated from your router. You can initiate a simple one if you just go into config mode and leave it. If you don?t see one you should think about an access list or anything else that prevents the trap to reache its target.

What is about a simple ping from router to Kiwi and vice versa?

New Member

Re: Ciscoworks IPM and sending SNMP traps

Yeah the Kiwi server appears to be working fine. It is also set up to recieve traps as this is not default. Everything looks like it should, however I can't get the traps to go to the Kiwi server. I know it will be something silly, but once working I can finally put IPM to some good monitoring use.

Here is one from this morning of me on the router in question. I had also set up debugging of the RTR and snmp and these were logged to the Kiwi server.

27-11-2006 09:41:45 Local7.Notice 10.24.70.2 37460: Nov 27 09:41:43 EST: %SYS-5-CONFIG_I: Configured from console by mwitte on vty0 (10.24.140.22)

Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

This is a syslog messages, not a trap. It doesn't sound like you have Kiwi setup correctly to receive traps.

New Member

Re: Ciscoworks IPM and sending SNMP traps

I have set up ethereal to capture data coming into the Kiwi server. I have had the over threshold 8 times and I see no traffic coming to the Kiwi server related to these traps. The Kiwi does collect other snmp related events and I do have the correct server. I would appear that when the threshold is crossed it does not send the trap as I do not see it even making it to the server

dr03-clt#sh ip sla monitor configuration 270

IP SLA Monitor, Infrastructure Engine-II.

Entry number: 270

Owner: 17|ipm-pkx66500102-mwitte

Tag: LTL_ECHO_1400

Type of operation to perform: echo

Target address: 10.1.60.18

Source address: 10.24.70.2

Request size (ARR data portion): 1400

Operation timeout (milliseconds): 3000

Type Of Service parameters: 0x0

Verify data: No

Operation frequency (seconds): 30

Next Scheduled Start Time: Start Time already passed

Group Scheduled : FALSE

Life (seconds): Forever

Entry Ageout (seconds): 3600

Recurring (Starting Everyday): FALSE

Status of entry (SNMP RowStatus): Active

Threshold (milliseconds): 77

Number of statistic hours kept: 2

Number of statistic distribution buckets kept: 1

Statistic distribution interval (milliseconds): 20

Number of history Lives kept: 0

Number of history Buckets kept: 15

History Filter Type: None

Enhanced History:

dr03-clt#sh ip sla monitor reaction-configuration 270

Entry number: 270

Reaction: rtt

Threshold Type: Immediate

Rising (milliseconds): 77

Falling (milliseconds): 74

Threshold Count: 5

Threshold Count2: 5

Action Type: Trap only

Reaction: timeout

Threshold Type: Immediate

Threshold Count: 5

Threshold Count2: 5

Action Type: Trap only

dr03-clt#sh ip sla monitor collection-statistics 270

Entry number: 270

Start Time Index: 11:50:40.322 EST Tue Nov 28 2006

Number of successful operations: 11

Number of operations over threshold: 3

Number of failed operations due to a Disconnect: 0

Number of failed operations due to a Timeout: 0

Number of failed operations due to a Busy: 0

Number of failed operations due to a No Connection: 0

Number of failed operations due to an Internal Error: 0

Number of failed operations due to a Sequence Error: 0

Number of failed operations due to a Verify Error: 0

RTT Values:

RTTAvg: 77 RTTMin: 75 RTTMax: 84

NumOfRTT: 14 RTTSum: 1083 RTTSum2: 83897

Start Time Index: 10:50:40.322 EST Tue Nov 28 2006

Number of successful operations: 115

Number of operations over threshold: 5

Number of failed operations due to a Disconnect: 0

Number of failed operations due to a Timeout: 0

Number of failed operations due to a Busy: 0

Number of failed operations due to a No Connection: 0

Number of failed operations due to an Internal Error: 0

Number of failed operations due to a Sequence Error: 0

Number of failed operations due to a Verify Error: 0

RTT Values:

RTTAvg: 76 RTTMin: 75 RTTMax: 84

NumOfRTT: 120 RTTSum: 9133 RTTSum2: 695235

Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

Check the "show snmp" output to see if the SNMP logging stats are incrementing for your host. You may also want to enable "debug ip sla monitor trace" for your operation to see if IP SLA is trying to send the traps.

New Member

Re: Ciscoworks IPM and sending SNMP traps

Unfortunately we are pulling mrtg stats from that router also so the SNMP will be incrementing. I was going to do the trace on one of the applications(270) but I had read it can be intensive on the router. Since this router runs all of our core applications and VOIP I am a little hesitant doing this. I have a 7200 in the lab I can try labing up. Since I do see the threshold being crossed in the sh ip sla monitor collection-statistics 270. wouldn't that show me the same as the trace? I guess what i am really looking for is what exact commands are needed to make this work so i can see if I am missing something silly. Thanks!

dr03-clt#sh ip sla monitor collection-statistics 270

Entry number: 270

Start Time Index: 15:50:40.831 EST Tue Nov 28 2006

Number of successful operations: 110

Number of operations over threshold: 4

Number of failed operations due to a Disconnect: 0

Number of failed operations due to a Timeout: 0

Number of failed operations due to a Busy: 0

Number of failed operations due to a No Connection: 0

Number of failed operations due to an Internal Error: 0

Number of failed operations due to a Sequence Error: 0

Number of failed operations due to a Verify Error: 0

RTT Values:

RTTAvg: 76 RTTMin: 75 RTTMax: 84

NumOfRTT: 114 RTTSum: 8670 RTTSum2: 659486

Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

The "show snmp" output will contain logging (i.e. trap) information that will not increment when MRTG polls the device. It should, however, increment when the device sends a trap.

Your configuration appears to be correct on the device. The threshold traps should be sent. Once you have the operation configured you only need:

snmp-server enable traps rtr

snmp-server host x.x.x.x traps community [rtr]

And you already have these commands.

New Member

Re: Ciscoworks IPM and sending SNMP traps

does it need to be informs instead of traps? I saw this doc. Don't want to change anything that would affect the actual monitoring of the device as it is our main hub router that everything goes through..

snmp-server enable traps rtr

To enable the sending of Service Assurance Agent (SAA) Simple Network Management Protocol (SNMP) notifications, use the snmp-server enable traps rtr command in global configuration mode. To disable SAA SNMP notifications, use the no form of this command.

snmp-server enable traps rtr

no snmp-server enable traps rtr

Usage Guidelines

SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.

This command controls (enables or disables) Cisco Service Assurance Agent notifications, as defined in the Response Time Monitor MIB (CISCO-RTTMON-MIB). The Service Assurance Agent was previously called the Response Time Reporter (RTR); the RTR syntax is retained in this command.

This command enables the following notifications:

?rttMonConnectionChangeNotification?(valid for echo or pathEcho operations only) A rttMonConnectionChangeNotification indicates that a connection to a target (not to a hop along the path to a target) has either failed on establishment or been lost and when reestablished.

?rttMonTimeoutNotification?A rttMonTimeoutNotification indicates the occurrence of a timeout for a SAA operation.

?rttMonThresholdNotification?A rttMonThresholdNotification indicates the occurrence of a threshold violation for a SAA operation.

?rttMonVerifyErrorNotification?A rttMonVerifyErrorNotification indicates the occurrence of data corruption in an SAA operation

The snmp-server enable traps syslog command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.

The following example enables the router to send SAA related informs to the host at the address myhost.cisco.com using the community string defined as public:

Router(config)# snmp-server enable traps rtr

Router(config)# snmp-server host myhost.cisco.com informs version 2c public rtr

Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

You do not need to enable informs. Traps are sufficient. The commands "snmp-server enable traps rtr" and "snmp-server host x.x.x.x traps public rtr" are good enough to send SNMPv1 traps.

New Member

Re: Ciscoworks IPM and sending SNMP traps

I will try to use the debug ip sla monitor trace 270 (our application is 270) sometime early am in the next couple of days. Anything else? Since it appears that my router config is correct and looking at the stats, I can see that I am crossing the threshold the question is why won't it send the stupid trap. Running ethereal show nothing coming into the Kiwi box from the router so I know it is not sending traps. I does however show traffic when you logon to the router or make a config change so I know it is sending traps. We had some trouble with a serial line a week ago and we saw plenty of syslog traps. I really do not know what else to check. Thanks so far!

Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

WHAT traffic do you see when you make a config change? Everything I've seen so far has been a syslog message. Traps are completely different. They are sent on UDP port 162. If the device isn't sending any SNMP TRAPS, a "debug snmp packet" would be useful.

As I said twice before, the "show snmp" stats before a threshold is crossed, then immediately after would also show if IOS is even trying to send a trap.

New Member

Re: Ciscoworks IPM and sending SNMP traps

I had looked at that earlier and I do not see the traps going up. Here are the snippets I just ran; As you can see there were 2 threshold violations, and no trap PDU's. I am sure it is a misconfiguration I just cannot find it.

dr03-clt#sh snmp

Chassis: dr03-clt Cisco7206-Ser# 72789415

2345007 SNMP packets input

0 Bad SNMP version errors

2199 Unknown community name

0 Illegal operation for community name supplied

20 Encoding errors

16567291 Number of requested variables

2703 Number of altered variables

1952333 Get-request PDUs

388382 Get-next PDUs

432 Set-request PDUs

2351388 SNMP packets output

0 Too big errors (Maximum packet size 1500)

85819 No such name errors

0 Bad values errors

0 General errors

2342788 Response PDUs

8600 Trap PDUs

SNMP logging: enabled

Logging to 10.24.160.20.162, 0/10, 4305 sent, 0 dropped.

Logging to 10.28.140.55.162, 0/10, 4295 sent, 0 dropped.

dr03-clt#sh ip sla monitor collection-statistics 270

Entry number: 270

Start Time Index: 17:42:26.164 EST Wed Dec 6 2006

Number of successful operations: 7

Number of operations over threshold: 0

dr03-clt#sh ip sla monitor collection-statistics 270

Entry number: 270

Start Time Index: 17:42:26.166 EST Wed Dec 6 2006

Number of successful operations: 14

Number of operations over threshold: 2

Number of failed operations due to a Disconnect: 0

Number of failed operations due to a Timeout: 0

Number of failed operations due to a Busy: 0

Number of failed operations due to a No Connection: 0

Number of failed operations due to an Internal Error: 0

Number of failed operations due to a Sequence Error: 0

Number of failed operations due to a Verify Error: 0

RTT Values:

RTTAvg: 76 RTTMin: 75 RTTMax: 84

NumOfRTT: 16 RTTSum: 1225 RTTSum2: 93867

dr03-clt#sh snmp

Chassis: dr03-clt Cisco7206-Ser# 72789415

2345043 SNMP packets input

0 Bad SNMP version errors

2199 Unknown community name

0 Illegal operation for community name supplied

20 Encoding errors

16567509 Number of requested variables

2703 Number of altered variables

1952361 Get-request PDUs

388390 Get-next PDUs

432 Set-request PDUs

2351424 SNMP packets output

0 Too big errors (Maximum packet size 1500)

85820 No such name errors

0 Bad values errors

0 General errors

2342824 Response PDUs

8600 Trap PDUs

SNMP logging: enabled

Logging to 10.24.160.20.162, 0/10, 4305 sent, 0 dropped.

Logging to 10.28.140.55.162, 0/10, 4295 sent, 0 dropped.

Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

Well, the router is sending traps which is good. I just now tested your configuration, and I am able to get rising and falling traps as well as a timeout traps, so your config is definitely good.

Go ahead and get the "debug ip sla trace 270" and "debug snmp packet" when one of the thresholds is crossed. Note: if a rising threshold violation has occurred, but the latest RTT value is still above the falling threshold, no more traps will be sent until the falling threshold is crossed.

New Member

Re: Ciscoworks IPM and sending SNMP traps

I'll try to get in early tommorow to do that. I know there is a.00001% chance that these debugs will affect anything, but i am very careful about touching anything in prod especially our hub MPLS router. I had a supervisor fail over on a couple of months ago just adding a vlan interface and all the phones went off line. Luckily it was 7am so it didn't affect anyone you just never know.

I agree that the router is sending traps, just not when the threshold is crossed as can be seen.

As can be seen here we have sent 16 more snmp pdu's since the last post.

dr03-clt#sh snmp

Chassis: dr03-clt Cisco7206-Ser# 72789415

2358128 SNMP packets input

0 Bad SNMP version errors

2199 Unknown community name

0 Illegal operation for community name supplied

20 Encoding errors

16676758 Number of requested variables

2703 Number of altered variables

1963697 Get-request PDUs

390120 Get-next PDUs

432 Set-request PDUs

2364525 SNMP packets output

0 Too big errors (Maximum packet size 1500)

86063 No such name errors

0 Bad values errors

0 General errors

2355909 Response PDUs

8616 Trap PDUs

New Member

Re: Ciscoworks IPM and sending SNMP traps

I have enable the debugs, crossed over the threshold, and have the results. It appears to work, however the sniffer does not show the trap being sent.

1) According to the debugs the threshold caused a snmp V1 trap to be sent to our syslog server

2) A sniffer trace on our internal network shows the syslog debug messages(udp 514) being sent to our syslog server x.x.160.2 showing the same thing as the debug on the router. It never shows a snmpV1 trap being sent. This is a capture on the same vlan as the routers snmp source and logging source x.x.70.2

3) A ethereal dump on the syslog server also shows no snmpV1 packet coming in. It does also show the syslog(udp 514) messages coming in showing the debug output on the router.

4) The Kiwi server has also captured these syslog messages.

So the problem appears to be;

a)Even though the IOS debug shows a snmpV1 packet being sent to x.x.160.2 from x.x.70.2, it appears to not really send it at least out the snmp source port like it said it did.

b)This trap is not adhearing to the configuration of our snmp source of the syslog server for traps, while it does for the syslog messages.

Debugging turned on

debug snmp packets

debug ip sla monitor trace 270

Please note that

x.x.70.2 is the router

x.x.160.20 is the Kiwi server

x.x.140.55 is the IPM server

Dec 8 08:29:33 EST: IP SLA Monitor(270) Scheduler: Starting an operation

Dec 8 08:29:33 EST: IP SLA Monitor(270) echo operation: Sending an echo operation

Dec 8 08:29:33 EST: IP SLA Monitor(270) echo operation: RTT=80

Dec 8 08:29:33 EST: IP SLA Monitor(270) Scheduler: Updating result

Dec 8 08:29:33 EST: SNMP: Queuing packet to x.x.160.20

Dec 8 08:29:33 EST: SNMP: V1 Trap, ent rttMonNotificationsPrefix, addr x.x.70.2, gentrap 6, spectrap 3

rttMonCtrlAdminTag.270 = LTL_ECHO_1400

rttMonHistoryCollectionAddress.270 = 0A 01 3C 12

rttMonCtrlOperOverThresholdOccurred.270 = 1

Dec 8 08:29:33 EST: SNMP: Queuing packet to x.x.140.55

Dec 8 08:29:33 EST: SNMP: V1 Trap, ent rttMonNotificationsPrefix, addr x.x.70.2, gentrap 6, spectrap 3

rttMonCtrlAdminTag.270 = LTL_ECHO_1400

rttMonHistoryCollectionAddress.270 = 0A 01 3C 12

rttMonCtrlOperOverThresholdOccurred.270 = 1

Dec 8 08:29:33 EST: SNMP: Packet sent via UDP to x.x.160.20

Dec 8 08:29:33 EST: SNMP: Packet sent via UDP to x.x.140.55

Dec 8 08:29:40 EST: SNMP: Packet received via UDP from x.x.140.55 on Serial2/0

Dec 8 08:29:40 EST: SNMP: Get request, reqid 13853, errstat 0, erridx 0

sysUpTime.0 = NULL TYPE/VALUE

rttMonEchoAdminTargetAddress.270 = NULL TYPE/VALUE

rttMonLatestRttOperCompletionTime.270 = NULL TYPE/VALUE

rttMonLatestRttOperSense.270 = NULL TYPE/VALUE

rttMonLatestRttOperTime.270 = NULL TYPE/VALUE

rttMonLatestRttOperAddress.270 = NULL TYPE/VALUE

Dec 8 08:29:40 EST: SNMP: Response, reqid 13853, errstat 0, erridx 0

sysUpTime.0 = 2284120129

rttMonEchoAdminTargetAddress.270 = 0A 01 3C 12

rttMonLatestRttOperCompletionTime.270 = 80

rttMonLatestRttOperSense.270 = 3

rttMonLatestRttOperTime.270 = 2284119372

rttMonLatestRttOperAddress.270 =

Dec 8 08:29:40 EST: SNMP: Packet sent via UDP to x.x.140.55

Dec 8 08:29:43 EST: IP SLA Monitor(270) Scheduler: Starting an operation

Dec 8 08:29:43 EST: IP SLA Monitor(270) echo operation: Sending an echo operation

Dec 8 08:29:43 EST: IP SLA Monitor(270) echo operation: RTT=76

Dec 8 08:29:43 EST: IP SLA Monitor(270) Scheduler: Updating result

Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

SNMP traps are sent to upd/162. The most likely cause for what you are seeing is an access-list or firewall somewhere between the router in question and the Kiwi server. This would explain why the router claims to be sending traps, but your Kiwi server doesn't see a one of them (even the non-rtr traps).

The best way to determine this is to put a sniffer directly on the router's outbound interface (i.e. the interface closest to the Kiwi server). See if the traps are showing up there.

New Member

Re: Ciscoworks IPM and sending SNMP traps

Good news. I have been able to get this to work by stopping and starting the snmp server on the router. I see packets on my Kiwi sniffer and also in the logs of the Kiwi. Now I just have to figure out how to get it to just send me a email on just those traps.....

Thanks for all the help!!!

This is from the Kiwi;

08-12-2006 18:02:25 Local7.Debug 10.24.70.2 community=r2fqb26q2td7pc8n enterprise=1.3.6.1.4.1.9.9.42.2.3 enterprise_mib_name=rttMonThresholdNotification uptime=-2007410855 agent_ip=10.24.70.2 generic_num=6 specific_num=3 version=Ver1 var01_oid=1.3.6.1.4.1.9.9.42.1.2.1.1.3.4632 var01_value=Den_ECHO_1400 var01_mib_name=rttMonCtrlAdminTag.4632 var01_value=Den_ECHO_1400 var02_oid=1.3.6.1.4.1.9.9.42.1.4.1.1.5.4632 var02_value="Hex String=0A F9 00 02" var02_mib_name=rttMonHistoryCollectionAddress.4632 var02_value="Hex String=0A F9 00 02" var03_oid=1.3.6.1.4.1.9.9.42.1.2.9.1.7.4632 var03_value=2 var03_mib_name=rttMonCtrlOperOverThresholdOccurred.4632 var03_value=2

OT I saw something about a patch coming out for DFM so it would accept rtt traps from this. Any ideas when it will come out??

Cisco Employee

Re: Ciscoworks IPM and sending SNMP traps

Unfortunately, there is no ETA on when DFM will support CISCO-RTTMON-MIB traps. It will most likely not be in the next DFM release.

New Member

Re: Ciscoworks IPM and sending SNMP traps

Thanks for all the help.

271
Views
5
Helpful
26
Replies