OMPING(8) BSD System Manager's Manual OMPING(8)NAMEomping — test IP multicast
SYNOPSISomping [-46CDEFqVv] [-c count] [-i interval] [-M transport_method]
[-m mcast_addr] [-O op_mode] [-p port] [-R rcvbuf] [-r rate_limit]
[-S sndbuf] [-T timeout] [-t ttl] [-w wait_time] remote_addr...
DESCRIPTION
The omping is program which uses User Datagram Protocol to determine if
computer is able to send and/or receive IP unicast and multicast or
Broadcast packets from the network. It's designed to be used in very sim‐
ilar way as ping(8) and also has some features of the fping(8) command.
Where ping(8) and omping differ is in who replies. In ping(8) replies are
sent by the operating system and with omping another instance of omping
sends the reply. This mean that omping must be running on all computers
to test sending/receiving IP multicast/broadcast. Its arguments are as
follows:
-4 Force usage of IPv4.
-6 Force usage of IPv6.
-C Display continuous statistics for every reply message.
-D Disable packet duplicate detection. Option is default for inter‐
val 0.
-E Default behaviour when every client is in stop state is to exit.
This may happen if all server sends stop message or if count
query messages was sent. This option changes default behaviour
and omping doesn't quit automatically.
-F Allow entering of arguments which are not allowed or not recom‐
mended by the specification. This is typically the interval
parameter. This option may be used multiple times.
-q Quiet output. Nothing is displayed except state changes and sum‐
mary. Option can be used twice and then only summary is dis‐
played.
-V Display version and quit. Option can be used twice and then
remote version is displayed.
-v Set level of verbosity. Parameter can be used multiple times to
achieve higher verbosity.
-c count
Number of request packets to send to each target. After sending
count query messages, given client is put to stop state and it is
no longer sending query messages.
-i interval
Wait interval seconds between sending each request packet. Float
values are supported in millisecond precision. It's possible to
set there 0 with meaning that packets are sent ether after previ‐
ous unicast reply is received or after 1 millisecond, depending
on which of these intervals is smaller. The default is to wait
for one second between each packet.
-M transport_method
Set transport method to use. This can be asm for Any-source Mul‐
ticast, ssm for Source-specific Multicast and ipbc for IP Broad‐
cast.
-m mcast_addr
Multicast or broadcast address to listen on for multicast/broad‐
cast answer messages. Default is 232.43.211.234 for IPv4 and
ff3e::4321:1234 for IPv6 multicast, or broadcast address of local
interface for Broadcast.
-O op_mode
omping can be running in three different modes. Default and rec‐
ommended mode for quick testing is normal mode, when omping
behaves like client and server together. It sends queries and is
able to respond them. Finally the client mode sends queries, but
never respond to other nodes.
-p port
Port to bind and listen on for both unicast and multicast/broad‐
cast messages. Default is 4321.
-R rcvbuf
Set socket rcvbuf. Minimum value for this option is 2048. If not
specified, rcvbuf is not changed and default OS provided value is
used.
-r rate_limit
Rate limit interval between two query messages to rate_limit sec‐
onds. Default value is same as interval given by -i option. Rate
limiting can be disabled by specifying 0 as value. Rate limiting
is by default disabled for -i with 0 seconds.
-S sndbuf
Set socket sndbuf. Minimum value for this option is 2048. If not
specified, sndbuf is not changed and default OS provided value is
used.
-T timeout
Specify a timeout, in seconds, before omping exits regardless of
how many packets have been received.
-t ttl Time-To-Live of sent packets.
-w wait_time
after omping is stopped (by sending SIGINT or timeout expire) it
is moved to special state when no queries are made and server
answer all queries by server response (stop message). This makes
possible to give correct (unbiased) result of lost packets on
other nodes. Default is 3 times interval or 1 second, depending
which one is larger. Also special value 0 can be used to not wait
at all or -1 which means wait forever (this can be still termi‐
nated by sending SIGINT).
remote_addr
List of addresses to test. One of them must be address of local
internet interface. This local address is used for bind and lis‐
tening on for unicast packets. It's also used to determine which
interface should be used for sending multicast/broadcast replies.
Program is normally terminated by SIGINT. After signal receive summary is
displayed. You can also display summary during running by sending SIGINFO
or SIGUSR1 signal.
When using omping for fault isolation, it should first be run against
local internet interface only, to verify that the local network interface
is up and running, and firewall is correctly configured. This mode is
available by entering only local IP address.
EXIT STATUS
The omping utility exits 0 on success, and >0 if an error occurs.
EXAMPLES
The following commands and output is a typical way how to find-out and
solve network problems using omping. In this situation, we have 3 comput‐
ers named node-01, node-02 and node-03 with IP addresses 192.168.1.101 -
192.168.1.103. Let's run the following command on all of them.
$ omping node-01 node-02 node-03
on all of nodes we should be able to seen similar output
node-01: waiting for response msg
node-03: waiting for response msg
node-01: joined (S,G) = (*, 232.43.211.234), pinging
node-03: joined (S,G) = (*, 232.43.211.234), pinging
node-01: unicast, seq=1, size=69 bytes, dist=0, time=0.192ms
node-01: multicast, seq=1, size=69 bytes, dist=0, time=0.284ms
node-03: unicast, seq=1, size=69 bytes, dist=0, time=0.279ms
node-03: multicast, seq=1, size=69 bytes, dist=0, time=0.360ms
The first two lines tell us, that node-02 (actual node) is waiting for a
response message from node-01 and node-03. The second two lines contain
information, that we were successfully able to send an init message and
also received a response message from remote nodes. Both of these mes‐
sages are unicast, so we are able to send and receive unicast messages on
a given port. If all of nodes are up and omping is running on all of
them, but we are not able to receive a response message, it's time to
check connectivity between nodes. First make sure that you are able to
ping(8) them. If so, make sure that your firewall allows port 4321 to
receive udp packets.
The next line tells us that we were able to receive a 69 byte unicast
response message from node-01, with a sequence number of 1. The distance
between the computers is 0 so they are on the same link net. Time between
send and receive packet was 0.192 ms, that is also the current average
time and lastly there were no lost packets.
The 6th line tells us the same information as the previous one, but the
received message is a multicast message. It means, that multicast is
probably well configured.
The 7th and 8th lines are same as previous two one but for node-03.
If the node is able to receive unicast packets, but never multicast, it
means that multicast configuration is incorrect. It's recommended to turn
off your firewall. If multicast packets start to arrive, great. If not,
the problem is hidden in the switches/routers between the nodes. Contact
your system administrator to allow multicast traffic on the switch or
router.
omping is terminated by SIGINT signal (CTRL-c). Summary statistics are
shown
node-01: unicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev =
0.177/0.301/0.463/0.073
node-01: multicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev =
0.193/0.335/0.547/0.090
node-03: unicast, xmt/rcv/%loss = 21/21/0%, min/avg/max/std-dev =
0.272/0.299/0.327/0.017
node-03: multicast, xmt/rcv/%loss = 21/20/4% (seq>=2 0%),
min/avg/max/std-dev = 0.347/0.388/0.575/0.055
Last line has additional information (seq>=2 %0) which means, that after
receiving first multicast packet with seq number 2, no other multicast
packet was lost. Because creating multicast tree is time consuming, it's
pretty normal to lost first few multicast packets. rcv field can also be
formatted like
node-01: unicast, xmt/rcv/%loss = 3/3+1/0%, min/avg/max/std-dev =
0.294/0.299/0.305/0.006
This means, that 1 duplicate packet was received. It's possible to find
out duplicate packet by looking to output and find line which has follow‐
ing format
node-01: unicast, seq=2 (dup), size=69 bytes, dist=0, time=0.469ms
SEE ALSOfping(8), ping(8)STANDARDSomping uses Internet-Draft draft-ietf-mboned-ssmping-08 as underlaying
protocol and tries to be as compliant as possible.
AUTHORS
The omping utility was written by Jan Friesse ⟨jfriesse@redhat.com⟩.
BUGS
- Some OSes may not have support for receiving TTL from packet. omping
then cannot provide distance information.
- Some OSes may not provide information about packet receive. Less pre‐
cise actual time is then used.
- omping highly depends on precise poll(2) and gettimeofday(3) func‐
tions. If OS doesn't provide at least milliseconds precision, results
may be incorrect.
BSD Jun 22, 2011 BSD
