ssmping/asmping

1
ssmping/asmping

• Stig Venaas
• venaas_at_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 ltSgt 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) (200163024120421143ff
  fee19fe0,ff3e43211234)
• pinging S from 200170017211d8fffe8f1f9b
• unicast from 200163024120421143fffee19fe0
  , seq0 dist15 time72.874 ms
• unicast from 200163024120421143fffee19fe0
  , seq1 dist15 time72.663 ms
• multicast from 200163024120421143fffee19fe0
  , seq1 dist9 time76.502 ms
• unicast from 200163024120421143fffee19fe0
  , seq2 dist15 time72.056 ms
• multicast from 200163024120421143fffee19fe0
  , seq2 dist9 time73.556 ms
• unicast from 200163024120421143fffee19fe0
  , seq3 dist15 time72.232 ms
• multicast from 200163024120421143fffee19fe0
  , seq3 dist9 time73.579 ms
• unicast from 200163024120421143fffee19fe0
  , seq4 dist15 time72.513 ms
• multicast from 200163024120421143fffee19fe0
  , seq4 dist9 time73.256 ms
• --- 200163024120421143fffee19fe0 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

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/publicati
  ons/draft-sarac-mping-00.txt
• http//www.utdallas.edu/ksarac/research/publicati
  ons/CIIT04-1.pdf
• Their idea is to extend IGMP/MLD
• Not much interest in IETF so far
• This does some of the same, but doesnt 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 ltGgt ltSgt 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_at_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, seq1 dist11
  time66.203 ms
• unicast from 130.59.35.130, seq2 dist11
  time66.042 ms
• multicast from 130.59.35.130, seq2 dist11
  time66.492 ms
• unicast from 130.59.35.130, seq3 dist11
  time66.515 ms
• multicast from 130.59.35.130, seq3 dist11
  time66.520 ms
• unicast from 130.59.35.130, seq4 dist11
  time66.316 ms
• multicast from 130.59.35.130, seq4 dist11
  time66.321 ms
• unicast from 130.59.35.130, seq5 dist11
  time66.407 ms
• multicast from 130.59.35.130, seq5 dist11
  time66.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

12
More interesting example

• sv_at_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, seq1 dist23
  time57.261 ms
• unicast from 158.38.63.22, seq2 dist23
  time56.032 ms
• multicast from 158.38.63.22, seq2 dist7
  time207.876 ms
• multicast from 158.38.63.22, seq2 dist7
  time208.567 ms (DUP!)
• unicast from 158.38.63.22, seq3 dist23
  time56.852 ms
• multicast from 158.38.63.22, seq3 dist21
  time70.352 ms
• multicast from 158.38.63.22, seq4 dist21
  time57.208 ms
• unicast from 158.38.63.22, seq4 dist23
  time57.910 ms
• unicast from 158.38.63.22, seq5 dist23
  time56.206 ms
• multicast from 158.38.63.22, seq5 dist21
  time57.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 thats 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 its 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