01-22-2009 11:16 AM
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=
Solved! Go to Solution.
01-22-2009 04:05 PM
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.
01-22-2009 12:09 PM
1. No. This feature wasn't added until IPM 4.1.
2. What type of operations are you sending to this target?
01-22-2009 02:10 PM
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=
01-22-2009 02:45 PM
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.
01-22-2009 03:33 PM
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=
01-22-2009 03:50 PM
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.
01-22-2009 03:59 PM
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=
01-22-2009 04:05 PM
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.
01-22-2009 06:45 PM
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=
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide