Solved: Ciscowork with IP SLA Responder question

jayshihlin · ‎01-22-2009

Hi Everyone,

I have IP SLA (Cat3560 with c3560-ipservicesk9-mz.122-46.SE) working with Ciscowork IPM (v2.6.0). I usually configured IP SLA from Ciscowork and it get to push to source device. However, I experience two issue and not able to find any solutions for it. Perhaps it is by default but just want to confirm it.

1. When I configured IP SLA from Ciscowork it get pushed to Cat 3560 and I am able to retrieve statistic and real time graphic fine. However, Ciscowork will not add collector into IPM if I CLI enter the IP sla commands in the switch. Are there anyway IPM will pickups the CLI collector in the switch and have those nice graph?

2. I am able to add Cisco SAA Responder in Targets just fine, and IPM is showing green light. I am able to add collectors from Source and target to Cisco SAA Responder and it shows historical statistics too. However when I want to check responder by type show ip sla responder it return with 0 controller message.

slaresponder#show ip sla responder

IP SLAs Responder is: Enabled

Number of control message received: 0 Number of errors: 0

Recent sources:

Recent error sources:

Any suggestions or opinions are greatly appreciated!

Best Regards,

=J=

Joe Clarke · ‎01-22-2009

Control messages are used for jitter. UDP echo is a basic echo (very much like ping). In fact, you don't need the responder to do a UDP or TCP echo. Just enable service udp-small-servers or tcp-small-servers, and you will have the echo service running. Both work the same way. What ever you send to the echo port gets replayed back to you.

View solution in original post

Joe Clarke · ‎01-22-2009

1. No. This feature wasn't added until IPM 4.1.

2. What type of operations are you sending to this target?

jayshihlin · ‎01-22-2009

Hi Joe,

Thanks again for quick reply.

I just adding an DefaultIpEcho, and Ciscoworks shows collector is running and start.

Here is show ip sla stat from source:

================

Round Trip Time (RTT) for Index 31779

Latest RTT: 1 ms

Latest operation start time: 14:04:40.950 PST Thu Jan 22 2009

Latest operation return code: OK

Number of successes: 2

Number of failures: 0

Operation time to live: Forever

============

ipslsource#show ip sla config 31779

IP SLAs, Infrastructure Engine-II.

Entry number: 31779

Owner: 131|ipm-ful-cw2k-ipm

Tag: respondertest_1

Type of operation to perform: echo

Target address/Source address: ###.###.###.###/0.0.0.0

Type Of Service parameter: 0x0

Request size (ARR data portion): 64

Operation timeout (milliseconds): 5000

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): 5000

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:

===========

ipslaresponder#show ip sla responder

IP SLAs Responder is: Enabled

Number of control message received: 0 Number of errors: 0

Recent sources:

Recent error sources:

ipslaresponder#

===================

Best Regards,

=J=

Joe Clarke · ‎01-22-2009

This type of collector does not need or use the responder. You can do an IP echo test to any IP node. It simply uses ICMP pings. The responder is required for enhanced UDP operations such as jitter probes.

jayshihlin · ‎01-22-2009

I see. Just a curiosity, I tried it was udp-echo from Ciscowork. It get pushed to source but showing NoConnection/Busy/Timeout.

But cli in source

ip sla 1000

udp-echo xxx.xxx.xxx.xxx 7 source-ip yyy.yyy.yyy.yyy source-port 7

ip sla schedule 1000 life forever start-time now

cli in responder

ip sla responder udp-echo ipaddress xxx.xxx.xxx.xxx port 7

and now counter shows increasing in the show ip sla responder.

Yes you are correct on tcp-echo and even though counter shows 0 in the responder but Ciscoworks shows graph. However, I am not sure why udp does not work from Ciscowork push but works fine in cli. Again Ciscowork can't gather cli input in the my IPM...

Thanks anyway!

=J=

Joe Clarke · ‎01-22-2009

Make sure UDP port 7 is open between source and target. You might also not want to set a source port of 7, but rather leave this up to IOS to decide.

jayshihlin · ‎01-22-2009

yes, its open. Actually both source and target are in same network (testing). Will try to poke it around and test out something with tcp-echo. Just want to make sure that even responder showing 0 control message but and still logging correctly!

Thanks!!

=J=

Joe Clarke · ‎01-22-2009

Control messages are used for jitter. UDP echo is a basic echo (very much like ping). In fact, you don't need the responder to do a UDP or TCP echo. Just enable service udp-small-servers or tcp-small-servers, and you will have the echo service running. Both work the same way. What ever you send to the echo port gets replayed back to you.

jayshihlin · ‎01-22-2009

Sorry for another quick question. Do you think enabling udp-small-servers / tcp-small-servers is safer or using ip sla responder or even lock it down to ip sla responder or even lock it down to "ip sla responder tcp-connect ipaddress 10.1.1.1 port 5000".

Thanks again!

=J=