IPM 4.2.0 and icmp-echo 0.0.0.0 problem

[greenamit]

Hi,

I'm having a problem with IPM.

We are running LMS 3.2 with IPM 4.2.0.

I used IPM to configure a device to perform a ping to an ad-hoc target, the source router was configured as:

ip sla 182611

icmp-echo 0.0.0.0

request-data-size 64

owner ipm|<name>

tag <tag>

ip sla schedule 182611life forever start-time now ageout 3600

The target device is an ad-hoc with an ip-address but the IP SLA job ends up as 0.0.0.0.

When I'm running 'show ip sla statistics' it shows that the ping are timed out (as they are being sent to 0.0.0.0 instead of the real IP address).

The source router is running:

Cisco IOS Software, 3800  Software  (C3825-ADVSECURITYK9-M), Version 12.4(22)T, RELEASE  SOFTWARE (fc1)

Anyone had familiar problems?

Thanks,

Amit

[Joe Clarke]

I haven't seen this before.  Can you redo the configuration, and collect a sniffer trace of SNMP traffic between the IPM server and the device?  This will help determine if the problem is with IPM or IOS.

[greenamit]

jclarke wrote:
I haven't seen this before.  Can you redo the configuration, and collect a sniffer trace of SNMP traffic between the IPM server and the device?  This will help determine if the problem is with IPM or IOS.

Hi,

My IPM is running on Solaris 10.

Can you advise what/how I can sniff the SNMP traffic between the server and the IOS device?

Here is more information from the device:

#show version
     Cisco IOS Software, C3550 Software (C3550-IPSERVICESK9-M), Version 12.2(46)SE, RELEASE SOFTWARE (fc2)

#show running-config | inc 154366

ip sla 154366

ip sla schedule 154366 life forever start-time now ageout 3600

ip sla reaction-configuration 154366 react timeout threshold-type immediate action-type trapOnly

ip sla reaction-configuration 154366 react rtt threshold-value 4000 3000 threshold-type consecutive 2 action-type trapOnly

35PROB#show ip sla configuration 154366

IP SLAs, Infrastructure Engine-II.

Entry number: 154366

Owner: ipm|unix107776a44

Tag: 35PROB_AMIT

Type of operation to perform: echo

Target address: 0.0.0.0

Source address: 0.0.0.0

Request size (ARR data portion): 64

Operation timeout (milliseconds): 5000

Type Of Service parameters: 0x0

Verify data: No

Vrf Name:

Schedule:

    Operation frequency (seconds): 60

    Next Scheduled Start Time: Start Time already passed

    Group Scheduled : FALSE

    Randomly Scheduled : FALSE

    Life (seconds): Forever

    Entry Ageout (seconds): 3600

    Recurring (Starting Everyday): FALSE

    Status of entry (SNMP RowStatus): Active

Threshold (milliseconds): 4000

Distribution Statistics:

    Number of statistic hours kept: 2

    Number of statistic distribution buckets kept: 1

    Statistic distribution interval (milliseconds): 20

History Statistics:

    Number of history Lives kept: 0

    Number of history Buckets kept: 15

    History Filter Type: None

Enhanced History:

Thanks

[srego4]

something similar i had with the same versions of IPM and LMS...

what I got from TAC was CSCsy37122    my ios versions (on catalyst switches) 12(40) and below work fine.  12.2 (50)se1 does not.  12.2 (50) se3 works fine <-- cisco fixed the bug here. i tested and IPM configs & manages the collectors fine with the new version.

so it maybe possible u are hitting something similar. 

[Joe Clarke]

This is my bug, and while it sounds similar, I never saw that the source address in the CONFIG was actually 0.0.0.0.  However, the other symptoms match.  This is why I was curious about the sniffer trace.  If it shows that IPM is doing the right thing, then the bug is most likely CSCsy37122.

[srego4]

hi joe,

here is a config from one of my switches (when i opened my TAC case)..... source address does show 0.0.0.0

Entry number: 198699
Owner: ipm|nscw2
Tag: collector name

Type of operation to perform: tcp-connect
Target address/Source address: 10.15.1.133/0.0.0.0
Target port/Source port: 25/0
Type Of Service parameter: 0x0
Operation timeout (milliseconds): 60000

ps.  thanks for the bug fix... but also noticed this issue only when I went directly to 12.2(50)  from 12.2 (40) i.e. IPM used to work fine with the old IOS

[Joe Clarke]

Yes, the output of "show ip sla conf" was used to confirm the bug.  However, I never actually saw the 0.0.0.0 value in a show run output.