CAIDA CoralReef Exercises





Introduction to CoralReef Applications



CoralReef is a set of programs for working with OcxMONnetwork monitors
and trace files that have been collected from OCxMON monitors. OCxMON
monitors collect data from ATM links carrying IP traffic at either OC3
(155Mbps --OC3MON) or OC12 (622Mbps --OC12MON).
(OC48MON is under development and plans for OC192MON are being made.)

A large number of ``packet header traces'', containing the first 48
bytes
Why 48 bytes?
of each IP packet are available at
http://moat.nlanr.net/Traces/
Typically the traces include data from two interfaces, one collecting
data from each direction.



The CoralReef package is available from
https://www.caida.org/tools/measurement/coralreef/.

Coral reef is intended as a developers environment to allow people to
develop code that works with traces and live monitors. There are a
number of sample programs included with CoralReef. Below are brief
notes about some of them.

Applications

Note: There is a bug in this program for release 3.1.1 of coral. To
correct it add the line:
use lib "/usr/local/Coral/lib"; #coral global libdir#
before:
use lib "../../lib";
at line 54 of the perl script in your
install/bin directory (/usr/local/Coral/bin on most systems).

crl\_hostmatrix

This program performs a similar function to crl\_ipmatrix except that it
resolves the IP addresses into domain names by doing an in-addr
(reverse) DNS lookup.

Notes: There is a bug in this program for release 3.1.1 of coral. To
correct it remove the -f from open(INFILE, "${script_path}crl_ipmatrix -f $ARGV[0] |")

This program is not useful on traces that have the IP addresses
encoded.

crl\_ipmatrix

This program produces a table of source and destination IP addresses
with a count of how many packets went in each direction between these
hosts. Before the main section the program prints the total number of
packets and the total number of bytes in the trace.

crl\_info

Prints information about the trace and the system it was collected on.

crl\_ipaddr

For each packet in the trace print the source and destination address
and the protocol being carried by the IP packet.

crl\_ipmatrix

Scans the trace for each IP source and destination pair. At the end
of the trace it prints the IP source, IP destination, number of
packets and number of bytes transfered.

crl\_llcsnap

Print out the all of the combinations of ATM headers
and LLC/snap values in the trace, separated out by interface. The
number of occurrences is shown first.

crl\_locality

Calculate source and destination address histograms for a Coral format
packet dump.

crl\_nonip

Print the LLC/SNAP header for each non-IP packet in the trace.

crl\_portsummary

Scans the trace and at the end of the trace prints a line for every
unique (interface, protocol, source port, destination port, packet\_size)
value. The line contains the interface, the IP protocol number, a
flag indicating whether the ports fields are valid for this protocol (1
means valid, 0 means invalid), the source port, the destination port,
the packet length and the number of packets that were in the trace
with these parameter.

To find the total traffic, with a given source and destination port,
each line that matches the required source and destination pair must
be found (these will be for different packet sizes). The packet size
multiplied by the number of packets should be calculated and added to
the total traffic.

crl\_print

Prints ATM cells in hex and ASCII. ATM headers are expanded to a more
readable form, unless the "-r" (raw) option is specified.

crl\_sample

An example program. It has a few more comments than normal!

Scans the trace file and at the end of the file prints the number of
IP packets, the number of data bytes transfered in IP packets. Then
the number of TCP packets and the number of IP data bytes in IP
packets that carried TCP packets is printed. I.E. all byte counts are
IP payload byte counts. That is the header is not included in the
byte count for IP and is included for TCP and the other protocols. It
also prints the number of TCP acks, TCP pushes, number of packets per
protocol, and the number of bytes per protocol.

Finally the number of packets and the byte count is printed for each
protocol carried inside an IP packet (i.e. based on the IP protocol
field.) This, of course, includes TCP, UDP, ICMP etc.

crl\_skel

This program is intended to form an outline for your own coral
programs. It is a generic C skeleton for libcoral based ATM cell
analysis applications. As it is provided it expects standard coral
command line arguments and prints the cells it receives.

crl\_timestamps

Prints one line per cell in trace. Each line has first column the
interface of the cell, then the absolute timestamp of that cell, then
the delta timestamp to previous cell on same interface.

crl\_toascii

Converts a CoralReef format file (or any format that coral reef
recognises) to ASCII.

The output contains: the interface, the total number of packets
processed so far, the time (in seconds), the time since the previous
packet, the IP source, the IP destination, the number of data bytes
carried in the IP packet, the source port and the destination port.
If the protocol is not TCP or UDP the source and destination ports are
(0, 0).

Note: Coral-3.0 has a bug in this perl script. The call to the
method config_get should be config_options.

crl\_tofr

Converts the input file to fr trace format.

Note: Coral-3.0 has a bug in this perl script. The call to the
method config_get should be config_options.

crl\_tofr+

Converts the input file to fr trace format.

Note: Coral-3.0 has a bug in this perl script. The call to the
method config_get should be config_options.

crl\_tos

Prints the percentage of packets with different values of the IP TOS
field on each and both interfaces.

vpvp

Collects information about the vpvc traffic from the trace. For each
vp:vc it reports the number of packets, number of bytes and number of
non-ip packets.

The output concludes with summary information for the hash table,
which is probably not of much interest unless you have very large
traces that are slow to analyse.

Notes: