Ciscoworks IPM and sending SNMP traps

[miwitte]

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

[Joe Clarke]

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.

[miwitte]

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?

[miwitte]

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

[Joe Clarke]

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.

[miwitte]

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

[Joe Clarke]

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?

[miwitte]

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??

[Martin Ermel]

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?

[miwitte]

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)

[Joe Clarke]

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

[miwitte]

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

[Joe Clarke]

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.

[miwitte]

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

[Joe Clarke]

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.