ssmpingasmping Stig Venaas venaasuninett no What is ssmping

ssmping/asmping Stig Venaas venaas@uninett. no

What is ssmping? l l l A tool for testing multicast connectivity Behavior is a bit like normal ping A server must run ssmpingd A client can ping a server by sending unicast ssmping query Server replies with both unicast and multicast ssmping replies In this way a client can check that it receives SSM from the server l And also parameters like delay, number of router hops etc.

How it works Client Server t t User runs ssmping <S> Client joins S, G Clients sends unicast to S Client receives replies and prints RTT and hops from server Client sends a new query every second Server receives unicast ssmping query Responds with ssmping unicast reply and multicast reply to G

Example output -bash-3. 00$ ssmping -c 5 -6 ssmping. erg. abdn. ac. uk ssmping joined (S, G) = (2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0, ff 3 e: : 4321: 1234) pinging S from 2001: 700: 1: 7: 211: d 8 ff: fe 8 f: 1 f 9 b unicast from 2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0, seq=0 dist=15 time=72. 874 ms unicast from 2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0, seq=1 dist=15 time=72. 663 ms multicast from 2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0, seq=1 dist=9 time=76. 502 ms unicast from 2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0, seq=2 dist=15 time=72. 056 ms multicast from 2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0, seq=2 dist=9 time=73. 556 ms unicast from 2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0, seq=3 dist=15 time=72. 232 ms multicast from 2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0, seq=3 dist=9 time=73. 579 ms unicast from 2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0, seq=4 dist=15 time=72. 513 ms multicast from 2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0, seq=4 dist=9 time=73. 256 ms --- 2001: 630: 241: 204: 211: 43 ff: fee 1: 9 fe 0 ssmping statistics --5 packets transmitted, time 5004 ms unicast: 5 packets received, 0% packet loss rtt min/avg/max/std-dev = 72. 056/72. 467/72. 874/0. 415 ms multicast: 4 packets received, 20% packet loss 0% loss since first multicast packet received (after 1077 ms) rtt min/avg/max/std-dev = 73. 256/74. 223/76. 502/1. 335 ms -bash-3. 00$

What does output tell us? l l 15 unicast hops from source, only 9 multicast, so tunneling likely Multicast RTTs are larger and varies more l l l Difference in unicast and multicast RTT shows one way difference for unicast and multicast replies, since they are replies to the same request packet Multicast tree not ready for first multicast reply, ok for 2 nd after 1077 ms No unicast loss, no multicast loss after tree established

Is it useful? l l l I believe it complements multicast beacons Useful for “end users” or others that want to perform a “one-shot” test rather than continuously running a beacon Are there other data than RTT and hops it should measure? l l Hops are measured by always using a ttl/hop count of 64 when sending replies It also gives a rough measure of how quickly the tree is built from receiver to source

History l Based on an idea by Pavan Namburi, Kamil Sarac University of Texas and Kevin C. Almeroth UCSB l l l Their idea is to extend IGMP/MLD l l http: //www. utdallas. edu/~ksarac/research/publications/draft -sarac-mping-00. txt http: //www. utdallas. edu/~ksarac/research/publications/CIIT 04 -1. pdf Not much interest in IETF so far This does some of the same, but doesn’t require network support l l Only uses UDP But it requires server to run ssmpingd

Summary l l l Tool and further documentation available from http: //www. venaas. no/multicast/ssmping/ You can deploy your own server, or check that you can receive from the public servers listed at the above URL Supports both IPv 4 and IPv 6 Currently it works for Linux, Solaris and Free. BSD. Probably also for other BSDs Client with reduced functionality available for Windows XP l IPv 4 only, no IPv 6 SSM available on XP

What is asmping? l l l l A tool for testing multicast connectivity Behavior is a bit like normal ping A server must run ssmpingd (latest version supports asmping) asmping is ASM version of ssmping A client can ping a server by sending unicast asmping query Server replies with both unicast and multicast asmping replies In this way a client can check that it receives ASM from the server l And also parameters like delay, number of router hops etc.

How it works Client User runs asmping <G> <S> t Server t Client joins G Clients sends unicast to S Client receives replies and prints RTT and hops from server Client sends a new query every second Server receives unicast asmping query Responds with asmping unicast reply and multicast reply to G

Example output [venaas@storhaugen ~]$ asmping -c 5 224. 1. 2. 234 ssmping. net. switch. ch ssmping joined (S, G) = (130. 59. 35. 130, 224. 1. 2. 234) pinging S from 158. 38. 63. 22 unicast from 130. 59. 35. 130, seq=1 dist=11 time=66. 203 ms unicast from 130. 59. 35. 130, seq=2 dist=11 time=66. 042 ms multicast from 130. 59. 35. 130, seq=2 dist=11 time=66. 492 ms unicast from 130. 59. 35. 130, seq=3 dist=11 time=66. 515 ms multicast from 130. 59. 35. 130, seq=3 dist=11 time=66. 520 ms unicast from 130. 59. 35. 130, seq=4 dist=11 time=66. 316 ms multicast from 130. 59. 35. 130, seq=4 dist=11 time=66. 321 ms unicast from 130. 59. 35. 130, seq=5 dist=11 time=66. 407 ms multicast from 130. 59. 35. 130, seq=5 dist=11 time=66. 956 ms --- 130. 59. 35. 130 ssmping statistics --5 packets transmitted, time 5000 ms unicast: 5 packets received, 0% packet loss rtt min/avg/max/std-dev = 66. 042/66. 296/66. 515/0. 326 ms multicast: 4 packets received, 0% packet loss since first mc packet (seq 2) recvd rtt min/avg/max/std-dev = 66. 321/66. 572/66. 956/0. 296 ms

More interesting example sv@xiang /tmp $ asmping 224. 3. 4. 234 ssmping. uninett. no ssmping joined (S, G) = (158. 38. 63. 22, 224. 3. 4. 234) pinging S from 152. 78. 64. 13 unicast from 158. 38. 63. 22, seq=1 dist=23 time=57. 261 unicast from 158. 38. 63. 22, seq=2 dist=23 time=56. 032 multicast from 158. 38. 63. 22, seq=2 dist=7 time=207. 876 multicast from 158. 38. 63. 22, seq=2 dist=7 time=208. 567 unicast from 158. 38. 63. 22, seq=3 dist=23 time=56. 852 multicast from 158. 38. 63. 22, seq=3 dist=21 time=70. 352 multicast from 158. 38. 63. 22, seq=4 dist=21 time=57. 208 unicast from 158. 38. 63. 22, seq=4 dist=23 time=57. 910 unicast from 158. 38. 63. 22, seq=5 dist=23 time=56. 206 multicast from 158. 38. 63. 22, seq=5 dist=21 time=57. 375 ms ms (DUP!) ms ms ms

What does output tell us? l l l l 23 unicast hops from source For multicast we first have 7, later stays at 21 We also get some info about loss and RTTs Number of hops is perhaps the most interesting In the stable situation with 21 there is probably native forwarding all they way Forwarding is probably on shortest path tree from source to receiver In theory we might also detect switch from RPT to SPT if number of hops are different l l l Number of hops on RPT are then probably larger than number of unicast hops But why only 7 hops initially? Why did we get the packet twice, and why do both have large ttl?

The mystery of the 7 hops l l So why only 7, and why large RTT and duplicate? The reason is MSDP and PIM registers In this case we know for sure that packets must have been encapsulated in MSDP. We are more than 7 hops away from UNINETT where the RP is. Assuming there are no other listeners, the packet was first encapsulated in PIM register going to the local RP. Then it was encapsulated in MSDP all the way to our local RP l l Not sure exactly when ttl is decremented with regard to register and MSDP, but in this case the receiver is 4 -6 hops from the local RP So that explains the number of hops, but why large RTT and duplicate?

Large RTT and duplicate l l So why the large RTT and duplicate? The reason is again MSDP l l l At least that’s theory The register packets are in this case passed with MSDP to the RP, and probably cached there When our (*, G) reaches our RP, we receive the packet from the cache, which by now is 200 ms old Next, our last-hop router switches to SPT, and what we think happens, is that the (S, G)-join also reaches the RP (RP is on the SPT path), and the RP again forwards it’s copy when this happens This also gives us a measure of how long the RPT to SPT switch did take, if we are correct in our speculations

Summary l l l It might be used to simply check connectivity, but also gives extra info like RTT and hops Compared to ssmping we might be able to derive some more interesting information due to the complexities of PIM register, MSDP and tree switching It supports both IPv 4 and IPv 6, and might have some interesting uses for testing IPv 6 embedded-RP Both asmping and ssmpingd should work on most systems, no SSM support needed See http: //www. venaas. no/multicast/ssmping/ for more info