1 / 16

ssmping/asmping

ssmping/asmping. Stig Venaas venaas@uninett.no. What is ssmping?. 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

anka
Download Presentation

ssmping/asmping

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ssmping/asmping Stig Venaas venaas@uninett.no

  2. What is ssmping? • 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 • And also parameters like delay, number of router hops etc.

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

  4. Example output -bash-3.00$ ssmping -c 5 -6 ssmping.erg.abdn.ac.uk ssmping joined (S,G) = (2001:630:241:204:211:43ff:fee1:9fe0,ff3e::4321:1234) pinging S from 2001:700:1:7:211:d8ff:fe8f:1f9b unicast from 2001:630:241:204:211:43ff:fee1:9fe0, seq=0 dist=15 time=72.874 ms unicast from 2001:630:241:204:211:43ff:fee1:9fe0, seq=1 dist=15 time=72.663 ms multicast from 2001:630:241:204:211:43ff:fee1:9fe0, seq=1 dist=9 time=76.502 ms unicast from 2001:630:241:204:211:43ff:fee1:9fe0, seq=2 dist=15 time=72.056 ms multicast from 2001:630:241:204:211:43ff:fee1:9fe0, seq=2 dist=9 time=73.556 ms unicast from 2001:630:241:204:211:43ff:fee1:9fe0, seq=3 dist=15 time=72.232 ms multicast from 2001:630:241:204:211:43ff:fee1:9fe0, seq=3 dist=9 time=73.579 ms unicast from 2001:630:241:204:211:43ff:fee1:9fe0, seq=4 dist=15 time=72.513 ms multicast from 2001:630:241:204:211:43ff:fee1:9fe0, seq=4 dist=9 time=73.256 ms --- 2001:630:241:204:211:43ff:fee1:9fe0 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$

  5. What does output tell us? • 15 unicast hops from source, only 9 multicast, so tunneling likely • Multicast RTTs are larger and varies more • 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 2nd after 1077ms • No unicast loss, no multicast loss after tree established

  6. Is it useful? • 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? • 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

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

  8. Summary • 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 IPv4 and IPv6 • Currently it works for Linux, Solaris and FreeBSD. Probably also for other BSDs • Client with reduced functionality available for Windows XP • IPv4 only, no IPv6 SSM available on XP

  9. What is asmping? • 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 • And also parameters like delay, number of router hops etc.

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

  11. 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

  12. 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 ms unicast from 158.38.63.22, seq=2 dist=23 time=56.032 ms multicast from 158.38.63.22, seq=2 dist=7 time=207.876 ms multicast from 158.38.63.22, seq=2 dist=7 time=208.567 ms (DUP!) unicast from 158.38.63.22, seq=3 dist=23 time=56.852 ms multicast from 158.38.63.22, seq=3 dist=21 time=70.352 ms multicast from 158.38.63.22, seq=4 dist=21 time=57.208 ms unicast from 158.38.63.22, seq=4 dist=23 time=57.910 ms unicast from 158.38.63.22, seq=5 dist=23 time=56.206 ms multicast from 158.38.63.22, seq=5 dist=21 time=57.375 ms

  13. What does output tell us? • 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 • 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?

  14. The mystery of the 7 hops • 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 • 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?

  15. Large RTT and duplicate • So why the large RTT and duplicate? • The reason is again MSDP • At least that’s the 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 200ms 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

  16. Summary • 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 IPv4 and IPv6, and might have some interesting uses for testing IPv6 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

More Related