Now it's time for discussion on IPSLA folks. So what is IPSLA in the world of Cisco?
So IPSLA is a tool that is built into our Cisco iOS devices. And this tool gives us the ability to continuously monitor our various aspects of our network.
In addition to monitoring, we can also measure the various aspects of our network. So what are some of these different aspects?
Things like delay. Delay from one point to another point. So when you examine this picture here, you can see that we have a connection from ourselves at one site to another site over a service provider's environment.
We have an agreement with our service provider. They provide us a service that meets certain levels, and we go ahead and we use that service. But if we don't measure that service continuously, we are not going to know if that service provider is actually providing the level of service that we're paying for.
We can't just take their word for it. You know what I mean? So in the end, we need a way to continuously measure things so we know if we are getting the levels that we need to provide the levels of service that we need.
So this is just one example of continuously measuring that environment to find out if we are getting what we're paying for. But there are many other reasons why we might want to use IPSLA.
So things like measuring delay, or jitter, or packet loss, packet sequencing, the path that is being taken, or just simple connectivity from point A to point B, round trip times, voice quality scores.
This is just a small, small example of what we could possibly do with IPSLA. IPSLA is massive, folks. And what we can do with it is astronomical. But for the certification exam, we have to stay focused, and we are going to focus on just what we need to know for this particular certification exam.
So what is the purpose of IPSLA? Well, if we can continuously monitor and measure our environment, then we will have the ability to fine-tune that environment. So we'll have the ability to do things like increase productivity, lower operational costs, reduce the frequency of network outages.
We'll be able to improve our troubleshooting capabilities. We'll be able to perform better problem analysis. And then in the end, we'll ultimately be designing better networks. So by constantly measuring what is going on, we'll have a better understanding of how the network is performing, and then we can tweak it to meet our needs.
So with IPSLA, we're actually doing a type of active traffic monitoring, folks. Active traffic monitoring. What does that mean? It means we're sending out a probe, as we call it. What is the probe? Well, the probe is anything that you can ultimately create with IPSLA to mimic other types of traffic.
So can I create a probe that mimics a voice packet? Sure. Can I create a probe that mimics a simple ping? Sure. Can I create a probe that mimics HTTP web traffic? Sure. So I can create various probes that mimic traffic types in my environment, and I can send these probes in a continuous, reliable, predictable manner.
So that way there, I can gather measurements based on that. So think about your voice traffic. If I could send a probe continuously, repeatably, reliably, predictably, that is like a voice packet, and continuously measure, measure, measure, measure, then we know exactly how our network is performing when it comes to those voice packets.
So if all of a sudden we see that, ooh, the round-trip time is not that good, or the one-way time is not that good, or the delay is not that good, or the jitter is not that good, and so on and so forth, we can fine-tune the environment. We might be able to find those deficiencies in the environment, like, oh, maybe we need to implement quality of service over here. So that way there, we can expedite, prioritize that traffic, that voice traffic to the front of the line. So that way there, it's not being held up by all that other TCP traffic that we have.
So we have the ability to constantly measure and collect that information. We can store that in the memory of the CLI, but it's also findable or stored in the SNMP management information base as well.
So when it comes to IPSLA, we have different operations that are supported. Now, not all operations are going to be supported on all Cisco products. Some Cisco products will support the set you see here. Some will support some more. Some will support less. So you won't be directly tested on, oh, which of the operational types are supported on a particular version of Cisco.
But you'll see here that we can send out probes that mimic things like DHCP, DNS, ECHOs, FTPs, HTTP, Jitters, MPLS, JitterPath, ECHOs, PAP, Jitter, TCP Connects, UDP, ECHO. So we have all these various options available to us.
And our focus is going to be on things like the Jitter aspect, the ECHO aspect for the certification exam. So for the certification exam, I'll give you some examples here based on things like testing a server's response time with an ICMP ECHO, testing network performance with UDP ECHO, failover for floating static routes, as well as monitoring the network for voice with UGP Jitter. So those are the things we are going to focus on to get ready for the certification exam.
Now, something to keep in mind is that in the HSRP discussion, you would have had an example there where you were using a ping probe to test straight up simple connectivity, meaning if we are able to connect through this interface to that particular destination, then we are going to leave our priority of our HSRP device at a certain value.
But if that ping fails, that probe fails, the SLA instance fails, the tracking object goes down, the tracking object goes down, we decrement our priority. If we decrement our priority enough, then we give up that active role and the standby device becomes active.
So we already saw an example of how we could use the IPSLA in that particular scenario. So we'll add these ones now to our repertoire, our arsenal of information that we have to get ready for the certification exam.
So the first thing we need to do is understand this terminology, IPSLA, IP Service Level Agreement Without Responder. That is kind of misleading, but that is how we say it. Without Responder simply means the device that's responding does not run IPSLA. That's all that means.
So IPSLA Without Responder simply means that we are using probes that the device who responds to understands those probes natively. It doesn't need IPSLA running in order for it to respond.
So something like a simple what? A simple ping, an echo, probe, all devices understand, an ICMP echo. So as a result of that, they can respond. So that is an example of IPSLA without a responder, simply meaning that I configure the source probe sends the probe.
I don't have to do anything on the responder or the responding device, I should say, because it already understands what to do with it because it's a protocol, a service that already understands. It knows what to do with it so that it can respond back. So when we're talking about IPSLA Responder, we're setting up in a way that the device in question that we're probing already understands the type of probe that we are using.
All right, so here's our environment we're going to play around with in this particular case as we do our examples. And so we are going to do some examples here. I'm going to do an example right now on DSW-1. We'll also do an example on R2. And this is going to be our target device over here in most of these examples.
So the first one I want to do is just a simple probe to show you how we can measure, one, connectivity. Do we have connectivity? And the round-trip time of that connectivity. So we'll set up a probe here on DSW-1. That probe is going to go out here, go there, and then come back.
And then we'll know what? We'll know whether we have connectivity, yes or no. And if we do have connectivity, then the question is, how long did it take to go from DSW-1 to the server and back? So this is a very simple example in this particular case because this example is going to be based on the fact that we're using ping. That's it.
So let's go ahead and reach out to DSW-1 right now. And on DSW-1, we're going to type in configure terminal. And we'll type in, well, you know what, let's do a ping first. Let's make sure we can ping that device, 192.0.2.5. All right, we can. That's good.
So actually, let's source that from the inside interface, so 10.40.12.1, so my SVI, 10.40.12.1. Let's do it from that IP address instead. And that works. So it's from our inside SVI all the way to that server and back.
So now let's go ahead and type in IPSLA. And we give it a number. So as you can see, you get many SLA instances on your device. So IPSLA1. And then I'm going to hit enter. Now we are in IPSLA1 configuration mode. So the 1 is just a number, probe number 1. So I've got 2 probes, 3 probes, 4 probes. I just number them differently.
Now what we're going to do is we're going to set up the probe. And in this case, we want to have an ICMP echo probe for our example. So it's a simple ping one. But you can see there's video operations, UDP jitter operations, UDP echo operations, path echo operations, HTTP, FTP, and so on and so forth on this device. ICMP echo in our example.
Next, what is the destination IP address we want to ping? So I'm going to be 192.0.2.5. And then what is our source interface or source IP address? So I'm going to say the source IP address we're sending this probe from, as an example, 10.40.12.1. Because I just want to test roundtrip time and connectivity from that summit, that VLAN, that broadcast domain, as an example.
All right. Now, how often are we going to do this? Let's say we want to do this every 5 seconds. That way there, I want to know every 5 seconds if that connection is up and running. And also, what is the roundtrip time every 5 seconds, so we know.
All right. So something as simple as that. Now, what we're going to do is we are going to turn it on. So IPSLA schedule. And then you got to specify the entry number. So I'm going to specify entry number 1. And then now, you'll see that we have different options, age outs, life, recurring, start time.
So, for example, you can schedule this to start every day at a certain time and then end every day at a certain time and just have this running maybe from 8 a.m. to 5 p.m. every day. Or you could have it running 24 hours a day, 7 days a week if you want to.
So how you schedule it is determined by how often you need to get those measurements, when you need to get those measurements. So it's going to be variable in regards to every probe that you create, meaning you're going to customize your schedule for every single probe that you have.
So I'm just going to type in here start time now, and I'm going to say life forever. But if I didn't say now, you'll see here start time. We can actually set up a schedule.
So if I say now, it means start now. And in lifetime, you'll see you can specify how long it lasts for. Or I can say forever, which means it never expires until I manually shut it off.
All right, so now the probe is running. So if we type in do show IPSLA configuration, you can see here that it tells us that our operation time out of milliseconds is 5,000. It's ICMP echo. There's the target address, the source address, any other type of parameters we specified, which we didn't specify any other types of parameters, but we can.
For example, like a type of service parameter, a particular request size, a data pattern, and all that stuff can be done here. Then we got our thresholds and so on and so forth. All right, now I want to check to see if it's working. So it's show IPSLA statistics.
And we'll see here that we have already sent eight probes. And the return status code is OK, meaning that everything is fine. We've had no failures at all. And you'll see here that our round trip time is one millisecond.
Because there's not a whole lot of stuff going on in this environment. But that is an example of what? Verifying testing connectivity and figuring out the round trip time of that. So let's go ahead and just break it. So if we go here, we say interface loopback 192.
I'm going to shut down that interface just to break that. So if we shut it down, we go back over to DSW1. And if we type in show IPSLA statistics, you're going to start to see some failures here. Why? Because the interface has gone down, which means the ping is not working anymore.
So it says no connection, busy timeout, failure one. Failure two, because remember, we're pinging every five seconds. So every five seconds, we're getting an update. There you go. So let's go back here. Let's re enable the interface.
And then we'll see here shortly that we start getting a round trip time back and our success to start going up there 18 with one millisecond again. Right. So perfect example of setting up a ping to test round trip time and testing basic connectivity.
Now, let's talk about doing a floating static route. So one of the things we learn in CCNA is the concept of a floating static default route. And so, for example, on router number two, we'll set up a default route.
Pointing to here, we'll set up a default route pointing to here, and then we'll set the administrative distance of this one, let's say, to seven. So that way, this is the primary route. This is the backup route.
So this one's only going to be installed in the routing table if this one's no longer in the routing table for whatever reason. Typically, the reason for this one not being in the routing table is that the interface is down. Now, the only way that interface is going to go down is if something happens to this connection or somebody brings down the interface.
The thing is, is most of the time, our networks are not going to have just a straight up cable from here to here from ourselves to our ISP. Why is that? Because there's going to be other layer one and layer two devices in between. Other layer one and layer two devices in between.
What does that mean? It means that our status of up, up on the interface is based on this connection from here to here. So if there's a failure here or here or here or here, my interface is still up, up. So if my interface is still up, up, then my default route is still in my routing table using that interface, even though the connection is down.
Because my interface is still up, up. So the default route is still in the routing table. Because that default route points to that particular interface using the next hop IP address. So it doesn't know that there's a problem further on down the line.
So the backup path with the higher administrative distance is not going to be installed in the routing table because this default route is still in based on the fact the interface is up, up. So what we can do here is we can actually set up a probe. So if I set up a probe and we constantly ping, ping, ping, ping, ping from that interface out, if that ping ever fails, then we can have this removed out of the table.
And then this one would be installed in the routing table instead. So that's what we're going to do here. We're going to set it up that way, where we have our primary path with an administrative distance of one. We have a secondary path with an administrative distance of seven.
And then we're going to set up an IP SLA instance, followed by a tracking object. And then we're going to attach the tracking object to the IP route command. That's what we need to do here to get this to work.
So over on R2, let's take a look to see what we have so far set up for our static routes. So run, pipe to section, IP route. We'll see here that we already have two specified in the table. So just to make this the same as our example, I'm going to take this one, I'm going to type a no, boom, break it, put it back in and change the administrative distance to seven.
Because we set ADF seven for the secondary path. Now we type in do show run, pipe to section IP route. It equals what we have in our example up here.
So our primary path goes through 203.01.13.89 because it has a lower administrative distance. Our secondary path goes through 192.02.241 with an administrative distance of seven. So if I type in do show IP route, we're going to see that the path through 203.01.13.89 is in the routing table.
Let's go ahead now and just bring down the interface. So interface FastEthernet 0.0.0. So it's the interface for the primary route. We shut that down. What we're going to see is that that route gets removed from the routing table because that interface to get to that next top IP address is no longer available to use.
So because that interface is no longer available to use to get to that next top IP address, the secondary route gets installed in the routing table.
And then when the interface comes back up, then that primary path has the lower administrative distance and it's now usable because the interface is back up. So what happens, it gets installed. The primary path gets installed back in the routing table.
So that's the basics here. But like I said, it's all dependent on that physical interface. So if we go to something like ISPA as an example, and I type in do show IP.
All right. Let's go to R2 right now. And instead, let's do this right now. Let's do, if I ping, do ping 8.8.8.8 or no 192. Let's do 192.0.2.5. That work? Yes. Let's repeat that.
Lots and lots and lots of times. Right. So it's working. Let's go over to ISPA right now. And what I'm going to do is I'm going to bring down interface VLAN1. I'm going to go ahead and shut it down.
So if I bring down that interface, what's going to happen here on R2 is that we lose connectivity. Why are we losing connectivity? Because we don't have the ability to get to the next top IP address.
The thing is the physical interface on R2 is still up up because we haven't affected the physical connection at all. The physical connection is still there. It's just that we have a problem in that environment. That's what I'm mimicking right now. There's a problem in that environment. But it doesn't affect my physical interface.
So if we type in here, let me break that sequence. Do show IP route. You'll see that that path is still in the routing table. This is a problem we have right now that I'm going to try and solve with IPSLA and tracking. So what we're going to do now instead is we're going to set up our probe.
So I'm going to bring this one back up. Go back to R2. All right, we're going to set up a probe now. And the probe, let's just do a ping again, make sure that everything's back up and running as it's supposed to. All right, it's working. So now I'm going to set up IPSLA. We'll call it SLA instance number one.
And now I'm going to say ICMP echo. And in this particular case, let's ping some address. Let's just ping some address in the service provider's environment. So do ping 8.8.8.8. All right, so that IP address is there. So let's go ahead and just say let's ping the ISPs IP address 8.8.8.8.
That's what we're going to do. So ICMP echo, destination address is 8.8.8.8. And the most important thing here is that the source IP address or the source interface, let's just say that's a better option here, is FastEthernet06060.
I'm making sure that it's coming from this physical interface because I want to test it from that physical interface to that IP address. So I want to test the primary link. It's important to get that interface proper. All right, now I'm going to do that, for example, every five seconds. So that way there we can detect a failure within five seconds and transition over to the backup link within five seconds.
I'm going to start that now. So IP SLA schedule for SLA instance number one that we're creating right here. And we're going to say start now, life forever. All right, so now let's take a look at do show IP SLA statistics and see if we're actually pinging successfully right now. And we are.
So let's go ahead now and bring down, for example, this interface again. So bringing down this virtual interface is an example of having a failure somewhere here in the ISPs environment, but it doesn't affect our physical interface on R2. And you'll see that there's failures happening now.
The ping is not reaching 8.8.8.8 anymore. So this is good, right? Why? Because I want to make sure that what we're doing is actually going to result in the outcome we're looking for. So I'm going to bring that interface back up, and we'll see here momentarily that those pings should start working again, and we should get a round trip. And there we go. So round trip, one millisecond, successful. All right, so we know that probe is working. It's accomplishing what we wanted to accomplish so far.
But we still have to attach it to our static default route. That's what we need to do. So that way our static default route can be removed from the table when the probe goes down. Now, how do you do that? You need what is called a tracking object, an intermediary feature between IPSLA and the actual default route.
So you create your tracking object by typing in track. Then you give it a number. So I'm going to give it number five here today for fun. And what do we want to track? We want to track the IPSLA probe. That's what we want to track. And what is the number of that probe? That was probe number one, if you remember. Okay, so put in probe number one there. And what do we want to track? We want to track the state of that probe.
We could just hit Enter, and it would be perfectly fine. It would still work for us, but I'm going to pick state here. And that's it. We don't have to do any other aspects, any other features as to tracking object. I just want to track the state of it. So now what we're going to do is we're going to type in show track.
When I type in show track, the result is that the state of IPSLA1 is up. So since the state of IPSLA1 is up or okay, then our tracking object is up. So I was reading that incorrectly. So IPSLA1 state right now is up. Yes, okay, I am reading it right. So IPSLA state is up. Why? Because our return code is okay.
So since everything's good, that means our tracking object is a-okay. That's what that means. So now watch what happens, and I'm going to just show you again. If we shut down that interface, the probe fails. Watch what happens to our tracking object. So I'm showing you inch by inch what is happening with these different features.
So with IPSLA statistics, we're going to start to see some failures. So now you're going to see the tracking object went down because the probe has failed. So if we look at track, it's down. So since we're down, that means the tracking object is down as well.
So now that we have that, we can apply it to our default route. So what we're going to do is we're going to go now back to R2. I'm going to bring up the ISPs interface first. Let's go back to R2, and I'm going to type in do show run pipe to section IP route. Notice the tracking object has gone back up for us.
Tracking object is back up. So what we're going to do is we're going to modify the primary route, the primary route. So I'm going to type in no and get rid of that primary route, and I'm going to put it back in. And now we're going to type in track, track, T-R-A-C-K. And what are we tracking? We're tracking that tracking object we created, which was object number five, tracking object number five.
So what does this mean? Only put this route in the routing table if the tracking object is up and the IP address, the next hop IP address is reachable out of a physical interface. So now it's based on those two conditions.
Is that next hop IP address reachable out of that interface? In this case, it's fast Ethernet 000 that gets to that next hop IP address and the tracking object is up. Both of those conditions must be true for that to go in the routing table.
So now if we type in do show IP route, we're going to see that it is in the routing table, the next hop of .89. So that's the primary path. We type in do show track. We'll see the tracking object is up. The tracking object is attached to our static routing.
And our IPSLA statistics, everything's good. So now let's just go ahead and bring down, make that virtual failure on our ISP side so we can see what's going to happen now. And this is what we want. This is what we've been waiting for. This is what we've configured all this for.
We're going to see here eventually that R2 is going to give us a message, a syslog message that says, hey, tracking object is down. So when that happens, we now know what? We know that our probe has failed and our tracking object is down, which means that the static route should be removed from the routing table now because the tracking object is down.
And the backup static route should be in the routing table.
And it is.
And so now we're using the backup path.
If it comes back up that link.
Eventually the ISP solves their problem as an example.
Then what we should see here is that the ping starts to work again.
The tracking object therefore goes up and therefore the primary default route can go back into the table. So tracking objects back up. Why? Because the pings working again.
The tracking object is therefore OK and up.
Therefore, in our routing table, we have our primary path back in.
All right, so there's another example of using IPSLA without a responder. In this case, we're using this concept to.
To improve the functionality of our floating static default route. So instead of the decision being purely solely on the status of the interface being up or not, now it's going to be based on the status of the interface being up or not.
In addition to the tracking object being up or not, based on an IPSLA probe that is going out along that primary link.
All right, so let's now talk about IPSLA with a responder. So a responder simply means that the device responding understands IPSLA. So it's going to be another Cisco device.
So in order to have a responder, you need a Cisco device that understands IPSLA.
So with IPSLA with a responder, essentially what happens is we have a control phase where we open the communication channel.
And then from there, we can probe, respond, probe, respond, probe, respond back and forth. And why is this important? Because we have the ability to gather hyper accurate measurements.
So any scenario that talks about you requiring hyper accurate measurements, you need to have a responder.
Set up that understands IPSLA. So in this case, here's our source and here's our responder device.
And then there are other devices in between. So what happens here now is that there are going to be timestamps that can be kept track of from here to here.
And from here to here. And we have the ability to now take into account those timestamps.
From here to here. And from here to here. And we have the ability to now take into account things like the processing that's going on as well.
Because we can take into account the processing that's going on, we can get one way measurements now.
Because this device, the source, can send the probe. The probe's processed. The probe's sent back.
But because of the timestamps that are put in, this device now can measure one way measurements for latency, jitter, packet loss.
Therefore, we get what? Hyper accurate measurements.
So based on the fact now that we're keeping track of when we created it, when it was received, how long it took to process, when it was sent again, when it was received, how long it took to process, factor all those things in, do a little bit of subtraction, and the end result is what?
One way timestamp and a one way timestamp in return.
So things like UDP Echo can do this for us. UDP Jitter can do this for us.
So let's talk about right now UDP Echo.
So UDP Echo gives us the ability to measure end-to-end response times between a Cisco device and another device that has the ability to understand UDP messages.
The thing is you don't need a responder, meaning you don't have to, with UDP Echo, have a responder.
You could use UDP Echo and send it to another device because pretty much all devices out there understand UDP Echoes.
But the thing is that you have the ability with UDP Echoes when you set up a responder, the ability to actually measure things like your delay.
And then also inner packet delay variance.
So with that in mind, you'll have the ability to get better measurements, more hyper-accurate measurements when you are using the responder with UDP Echo.
So just by specifying UDP Echo, the destination IP address.
Now in this case, I didn't put a source IP address or anything like that, but yes, you could put a source IP address there, source ports, destination ports, the frequency, all of that, even thresholds and other values.
But like we said, we're just touching the surface of IPSLA to get you ready for the exam.
Notice the configuration on the responder is pretty simple.
IPSLA Responder.
Now if you want to specify specific port numbers and specific protocols to respond with, then you can absolutely put that information in there as well.
But in its basic sense, by typing in IPSLA Responder, default values can be used and you can get the responses back you need.
Minimal configuration, as you can see, on the responder.
But now, if you need to specifically target voice, as an example, UDP Echo is not the best option.
You want to target real-time traffic, real-time applications.
There's something better than UDP Echo, and that is UDP Jitter.
So UDP Jitter can diagnose real-time traffic applications like voice over IP, video over IP, real-time conferencing applications and solutions.
So what exactly does Jitter mean?
If you don't know, Jitter means the inner packet delay variance.
UDP Echo can give us kind of that, but not as good as UDP Jitter.
So I always pick, I always go with, especially for a Cisco exam, any scenario that's talking about IPSLA, anything about voice, anything about video, anything about real-time conferencing, UDP Jitter is the way to go for that one.
And if you don't know exactly what we mean by inner packet delay variance or Jitter, let me give you a little bit more information about that.
So think about when packets are sent consecutively in order.
So I send a packet, send a packet, send a packet, send a packet, so think voice.
I send it, I send it, I send it, I send it.
Okay, what is the best scenario for that?
The best scenario is that we want the delay between those packets to be the exact same.
We really do.
I want the delay between every single voice packet, if I can, let's say to be 10 milliseconds.
That way there, there's consistency for the receiving device.
But if there's any variation in that delay, let's say one of those packets, the difference between one packet and another is 10, the difference between that packet and another is 12, the difference between that packet and another is 15, and then that one and that one is 10, and then that one and that one, right, that is what Jitter is, the variation in delay between those packets.
And we really don't want a lot of Jitter, right?
We want that ultimately to be zero if we can, so that way their delay between every single packet is the exact same.
But it's not necessarily going to be that way for us in our environment.
We strive for that using quality of service and different things like that, but it doesn't necessarily happen exactly like that for us.
So we try to keep Jitter as low as possible, the variation in delay between voice packets.
So the key here now is we want to measure that stuff.
If we can constantly measure our environment for that, then we'll know if our environment is performing the way it needs to perform to accommodate that type of traffic.
So UDP Jitter is great for what?
Real-time voice over IP, video over IP, video conferencing.
Because I can measure the network's performance.
I can measure its delay.
I can measure its Jitter.
I can measure all of that stuff.
So in this case, an example, there's UDP Jitter, the IP address, the port number.
Again, you can do source port.
You can do many options here.
But to keep it simple for the exam, right, getting ourselves ready, UDP Jitter, destination, destination port.
If you need a IP address source port, then you can put it in there as well.
If not, the source port is just going to be randomly generated, and the source IP is whatever the exiting interface is for the probe.
So if you don't specify the exiting IP address, then in the end, it's just whatever interface it goes out of based on the routing table information.
So if you need to be specific, put in a source IP as well.
And again, we started this one now, life forever.
But the key here is to look at what we've got on the next few pages.
In this case, we've got a UDP Jitter operation set up.
So target address.
And notice the source address ends up being 000 in this particular case, ending with a port.
So it's whatever the IP address is when the probe gets sent out of an interface.
That's the one that becomes a source and the destination, and the port will be whatever is generated by the device.
Now, with IPSLA statistics, here's the cool stuff.
You see, we've got our UDP Jitter operation.
As you look down here, latency one way, one way.
So UDP Jitter gives you one-way measurements.
Number of latency, one-way sample, source-to-destination latency, destination-to-source latency.
So we have the ability to do those calculations that I was saying, because we have our source and our responder in our particular case.
And there's our Jitter.
Our Jitter.
Pocket loss as well, and so on and so forth.
So here's the wrap-up to this.
You might see UDP Echo on the exam.
You might see UDP Jitter on the exam.
If you see both UDP and Echo in the same question, I would gravitate towards UDP Jitter as my answer.
Especially if it's about voice, especially if it's about video, things like that, all right?
If the question is still about voice and video, but there's no UDP Jitter option, but there's a UDP Echo option, then I want you to pick UDP Echo.
And don't forget that both of these work best, UDP Echo and UDP Jitter, when you have a responder.
When you have a responder.
You don't need a responder, right?
I could set all this up without a responder, but then I don't get what?
I wouldn't get my Jitter, my one-way measurements, my Jitter, and all that stuff.
I wouldn't be able to calculate that.
So with a responder, you get the extra stuff.
Without the responder, you don't get the Jitter.
You don't get the latency and all that stuff.
All right, so that is our coverage of IPSLA to get you ready for the Encore certification exam, folks.
So review that a few different times.
Take note of what I showed you.
Take note of what I explained to you.
So that way there, nothing throws you off when you get maybe one or two questions or max three for IPSLA on the certification exam.