From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Sun Jan 04 2009 - 23:39:43 ARST
I don't really remember specifics. Packet loss measurement is also cited
as something a responder enables, and I would guess that jitter also
needs it.
As usual, no magic here. Think about what can be done without support
from the other side. That should be doable without a responder (but
with the help of some server nevertheless).
-Carlos
Roger RPF @ 4/01/2009 19:00 -0200 dixit:
> 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