This video was created for an actual Spirent customer's use case (i.e., the IP information depicted is specific to them). Otherwise, it can be generalized for any use case whereas a customer needs to run a one-armed remote network test, from a single Spirent TestCenter chassis, and still be able measure statistics beyond just simple continuity such as frame loss and latency.
Course: Spirent TestCenter Continuing Education course Series: Essentials of Courses Run Time: 5 min
There are situations where Spirent customers own just a single Spirent TestCenter chassis, and/or their test equipment is located in just in a single location, but they still need to test out to another site. This could be the case when their test equipment is located at a central site and they need to test links out to remote site(s). This could also be the case whereas tech has say a portable C1 chassis, for example, and carries it with him to remote sites to test the links back to a central site (or other remotes sites, etc.). In either case, you may need to perform an "one-armed" test from a single Spirent TestCenter chassis.
Spirent TestCenter chassis have built in clocks. These clocks have a Latency Resolution of 10 nsec; 2.5 nsec for 40/100 Gigabit ports. A single chassis is by default synchronized to itself. Spirent test frames include a "signature field" in the payload which is transparent to most packet forwarding devices. The signature field contains additional information which Spirent TestCenter ports can use to calculate more detailed test results. This information includes where the frames came from (which chassis, module, test port), their sequence relative to the other frames (so it can detect lost frames), and a timestamp which it can use to determine how long it took to be received (i.e, the latency).
Normally when you either have multiple chassis, say one local and one remote, the chassis are synchronized using GPS or CDMA to be able to provide this information for one-way measurements. But sometimes it is not possible for customers to deploy a chassis at both sites. So the issue that is addressed in this video is how you can generate traffic out of a single test port, to some remote site device, and have it received back on the same test port for recording the results. The question is how could that happen and still keep the signature in tack; and why would a remote device be willing to send the frame back.
The answer is simple thanks to the early inventors of the internet protocols; specifically the function of and ICMP echo request commonly known as ping. You see in their infinite wisdom they specified that an ICMP echo request can have a payload of arbitrary data and length. Then when the target of such a packet sends the corresponding an ICMP echo reply it must send it back with the payload unmodified. And since the payload is where the Spirent TestCenter Signature field resides, when it is received back it can be used by the same test port that sent it to measure the round trip statistics of the link.
To accomplish this you would configure a Raw Stream Block so as to "simulate" an ICMP Echo request to the remote device, and, that would include the Spirent TestCenter signature field in the test frame (i.e., data-plane frame). Because simply pinging from a Spirent TestCenter Device would not accomplish this since that is an actual "emulated" control-plane frame and therefore would not include the Spirent TestCenter signature field.
The caveat of using this technique is twofold. First, this is a round trip measurement so if there is a performance issue you don't know if it occurred on the way out, the way back, or both. Second, performance is also based on a remote device’s ability to respond to a ping. Especially for the latter it is recommended that the simulated ping packet be sent at a low rate so as not to overwhelm the remote device. Actually, there is a third caveat as well, that is the system under test needs to allow and end-to-end ping.
Select the Video Play Button below: