From: Roger RPF (rpf@bluemail.ch)
Date: Sun Jan 04 2009 - 19:00:00 ARST
Thanks for the information but I have to ask some more...I think this topic
is really not well described on the DocCD....
The interesting thing for me is, that if I configure the example below, I
do not see any difference in the results when I execute a sh ip sla monitor
stat det, whether I use the responder or not.
So if I understand it right, for the ip sla option described on the doccd, I
do not really need the responder. I would need it only if I specify sending
a test on a special port, using the option
R9(config)#ip sla mon responder type ?
frame-relay Setup Frame Relay responder
tcpConnect Setup tcpConnect responder
udpEcho Setup udpEcho responder
But what is the need if I only configure ip sla mon responder without any
options?
regards
Roger
-----Urspr|ngliche Nachricht-----
Von: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Im Auftrag von
Carlos G Mendioroz
Gesendet: Sonntag, 4. Januar 2009 12:06
An: CiSco Champ
Cc: Roger RPF; ccielab@groupstudy.com
Betreff: Re: ip sla monitor responder
I think it's a litle bit different.
ip sla use is to measure times (and availability). For so doing, it can
use existing services/protocols that your network has in place like icmp
echo, udp echo, a web http server or even a sip server. But as thoes
servers do not know anything about ip sla, you are restricted to getting
round trip times/performance (you can not tell appart what happened in
the forward and the return path, and you can not tell appart what
happened in the network vs. in the remote server, like a memory hog).
If you want more data, you can enable the responder as a server (at the
other side, usually many of them). They cooperate whith ip sla by adding
time stamps to the probes, so now you can tell where the problem lies.
-Carlos
CiSco Champ @ 3/01/2009 12:35 -0200 dixit:
> Hi,
>
> If you are generating and sending any udp traffic like multicast, you
don't
> need responder but if you generate taffic that need response like tcp then
> you need it on other side. Like i configure ip sla for multicast
> verificatioin and testing and no need of responsder but when i want send
> packets of tcp 23 etc then i need to configure responder.
>
> HTH
> Regards
>
> On Sat, Jan 3, 2009 at 6:20 PM, Roger RPF <rpf@bluemail.ch> wrote:
>
>> Hi Group,
>>
>> Somehow I do not understand if and why we have to configure the ip sla
>> responder. On the doccd
>>
>>
http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsoverv.
>> html#wp1063767
>> it says that configuring the responder is not necessary for all cisco sla
>> operations.
>>
>> If I go further and check the chapter using udp echo
>>
>>
http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsudpe.h
>> tml
>> it mentions to configure the responder but also with a note that it is
not
>> necessary.
>>
>> For which reason do we need the responder? I configured the setup with
and
>> without responder, both seem to work but checking the trace I see that
with
>> configured responder, a hash is inserted .
>>
>> Can someone explain this more detailed? What is this control message the
>> doccd mentions between sender and responder?
>>
>> many thanks in advance
>>
>> Roger
>>
>> --------
>>
>> Below the config and the trace outputs:
>>
>> -<R7-sender>---<R6>---
>>
>> R7:
>> ip sla monitor 10
>> type udpEcho dest-ipaddr 200.0.0.6 dest-port 5000 source-ipaddr
200.0.0.7
>> frequency 10
>> ip sla monitor schedule 10 life forever start-time now
>>
>> R6: (optional responder)
>> ip sla monitor responder
>>
>>
>> Debug on R7 without responder:
>>
>> Jan 3 15:13:24.459: IP SLA Monitor(10) CtrlMsg: Timeout
>> Jan 3 15:13:24.459: IP SLA Monitor(10) CtrlMsg: No connection
>> Jan 3 15:13:24.459: IP SLA Monitor(10) Scheduler: Updating result
>> Jan 3 15:13:29.447: IP SLA Monitor(10) Scheduler: Starting an operation
>> Jan 3 15:13:29.447: IP SLA Monitor(10) CtrlMsg: Sending msg, ver=1,
>> id=101,
>> len=52, cmd=2, ip=200.0.0.6, port=5000, duration=5000ms
>>
>> Debug on R7 with responder:
>>
>> Jan 3 15:14:49.454: IP SLA Monitor(10) CtrlMsg: Receive status = 0
>> Jan 3 15:14:49.458: IP SLA Monitor hash insert : 200.0.0.7 50441
>> Jan 3 15:14:49.458: IP SLA Monitor(10) udpEcho Operation: Sending udp
>> packet
>> Jan 3 15:14:49.458: IP SLA Monitor(10) udpEcho Operation: RTT=1
>> Jan 3 15:14:49.458: IP SLA Monitor hash remove: 200.0.0.7 50441
>> Jan 3 15:14:49.462: IP SLA Monitor(10) Scheduler: Updating result
>> Jan 3 15:14:59.451: IP SLA Monitor(10) Scheduler: Starting an operation
>> Jan 3 15:14:59.451: IP SLA Monitor(10) CtrlMsg: Sending msg, ver=1,
>> id=114,
>> len=52, cmd=2, ip=200.0.0.6, port=5000, duration=5000ms
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI ArgentinaBlogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:36 ARST