02-12-2023 02:58 AM
Hello,
I need to develop a router that will be the responder side of Cisco's IP-SLA UDP-JITTER VOIP command, can someone tell or point me to where I can find the details of the network send and reply packets format of that protocol?
Some specific questions:
What can be the length of those packets? is it always 32 bytes or can be different?
I know that one of the packet's fields is a timestamp, how does this timestamp is calculated?
Is there a difference in packet structure and values between using the control packet first to not using it?
thanks,
Eitan.
02-16-2023 08:47 AM
You are right I check the link you share and later I will do lab I will change the time Zone in one end and try to read it in Wiresharke.
but again it not so simple it need more work in real network.
I will update you soon
02-16-2023 07:05 AM
BTW, that Wireshark reference is interesting.
It seems to imply Cisco has not publicly revealed all the workings of their SLA technology.
02-16-2023 07:14 AM
02-16-2023 08:09 AM
There is another possible approach, to possibly solve your problem (which I'm not fully aware), which you might consider.
Rather than trying to get this function to work on your non-Cisco device (router?), or replace your non-Cisco device with a Cisco device, add an additional Cisco device, just for this function, "behind" your Cisco device.
Many, many years ago, I vaguely recall being involved where there was a need for us to monitor actual network performance (probably to prove the performance issue was NOT the network). What we did was setup a very inexpensive remote Cisco router (e.g. low cost ISR 800?) on the same network as problem host(s), often with connection to same physical edge device, and monitor end-to-end using it. (NB: the remote, inexpensive, router was only used, in this situation, as an end point for the SLA tests.)
02-16-2023 08:21 AM
02-16-2023 09:09 AM
". . . router I need to implement this protocol on suppose to replace a Cisco router.."
Yea, I thought that, which, again, is why I mention using an inexpensive Cisco router (not the one you're replacing), behind the non-Cisco router. I.e. It's just another "host" behind the non-Cisco router, and not being used as a router.
That said, it's certainly more "convenient" being able to use the non-Cisco router, as a direct replacement for the Cisco router (maintaining all currently used features), without needing any other (or Cisco) hardware (but, laugh, I think that's what Cisco wants).
There are possible advantages to what I suggest are: first, it might actually be "cheaper" in the long run (there's cost to your time to get this result); second, don't know where in the world you are, but in the USA (some other countries too?), reverse-engineering exposes you to some nasty liabilities. (The latter, might have very low odds being applied to you, but you're creating risk. [Possibly, some reverse-engineering liabilities is why Wireshark hasn't try to figure out more.]) Third, what if Cisco "enhances" this feature, assuming you too would like to use such an enhancement, you're back to spending your time to figure out the changes and incorporate them.
02-17-2023 02:13 AM
02-17-2023 10:11 AM
I truly understand.
I had about 40 years in IT, 30 of them as an independent "consultant". I.e. high on the priority list, keeping your customers happy.
However, if I believe customer was "shooting themselves in the foot", I would explain why I thought so. Sometimes they would change their mind. Sometimes they wanted to continue on as they desired. (In the latter, never felt it was my job to convince them to do something else, just my job to inform them of facts they may have not considered. [Also, sometimes customers have a really good reason for doing what they want, but for various reasons, cannot share such with you.])
Wish you the best success, and if you can, post a follow-up how it all worked out.
02-21-2023 11:30 AM
03-14-2023 12:11 AM
Joseph, I had some progress with this, didn't fully finish it since some other issues need my attention now, but after I implemented this protocol according to the Wireshark page and traffic capture it seems to work fine - both the control phase and the measurement phase, my side is the responder to Cisco's ip sla requests, according to Cisco ip sla statistics it seems it accepts correctly the response packets
03-14-2023 07:01 AM
Congratulations!!!
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