Customer Service Center

Environment/Versions Spirent TestCenter all versions IGMP/MLD Answer There are some scenarios will you see "weird" or unexpected join/leave latency measurements. If there are multiple clients in the same subnet (i.e., broadcast domain) As you can already determine by understanding multicast, there is no way to determine join/leave latency for a client in the same subnet as a client that has already joined the same group (or is not the last client to leave the group). If you do have multiple clients in the same subnet then: What happens is Spirent TestCenter will use the correct join and leave reports but the same multicast packet as the reference.   For example in the joins, you'll see that the same frame is being used as the first multicast packet for both clients.   Likewise on the leaves, the same frame is used as the last multicast packet. Why is Spirent TestCenter doing this?   As mentioned, you can already determine this by understanding multicast, because both clients are on the same vlan (same subnet), there is only one multicast stream and so has no choice but to use the first and last packets from it to determine the join and leave latencies.  This is working as designed. Is there a way around this? The IPTV test will make a distinction in that if it’s not the first host to join or the last host to leave on a broadcast domain. So basically this action is to not give any join/leave latency values for clients that are not the first to join or last to leave. Other than not display latency values for clients that do not affect the multicast traffic, the workaround would be to simply use only one client per broadcast domain (e.g. vlan / subnet). Here is a screen capture from a test from which you can use the attached pcap, "join-leave latency - sanity check.pcap" to see the result of having two hosts on the same subnet joining the same group. Another scenario is if "Stream Only Generation" (SOG) is disabled on the stream block that is transmitting the multicast stream to multiple groups.  For example say the stream block is setup to send to 5 multicast groups, 225.0.0.0 - .4. If SOG is disabled then all the flows will use the same Stream ID.  That is there's a 1:5 correspondence between stream ID:multicast group       What happens is STC will use the correct join and leave reports but the same multicast packet as the reference.   For example in the joins, you'll see that the same frame is being used as the first multicast packet for all the multicast groups.   Why is STC doing this? The Analyzer is configured to filter on the Stream ID (and not the multicast group address). Typically this is ok since by default SOG is enabled and therefore there's a 1:1 correspondence between stream ID:multicast group but without the 1:1 correspondence the multicast traffic for all 5 groups is treated as the same one. So although STC is using the correct join and leave reports it is using the first and last packet from that stream regardless of the multicast group for join and leave latencies, respectively Here's the screen shot of the joins for group 225.0.0.0 - .4 along with the first few multicast packets along with the calculated join latencies. From Wireshark (see attached pcap, "ss - 4.64 - rev a - 2 port 3918 join-leave latency test - sog OFF.pcap")         From the Results Reporter From a spreadsheet used to calculate the join latencies from the Wireshark timestamps.  Note the use of packet 13's timestamp as the first multicast packet Is there a way around this? Yes, simply enable (i.e., check) SOG (Stream Only Generation) on the multicast stream block.   Attachments Attachment join-leave latency - sanity check.pcap Attachment Description join-leave latency - sanity check.pcap Attachment ss - 4.64 - rev a - 2 port 3918 join-leave latency test - sog OFF.pcap Attachment Description ss - 4.64 - rev a - 2 port 3918 join-leave latency test - sog OFF.pcap