CAIDA is actively expanding the number of protocols that are supported in CoralReef as technology evolves. See the protocols section in the command usage document for the latest information on which protocols are presently supported.
Probably not. Currently, VC filtering must be done in software.
For analysis above the AAL5 reassembly level,
the
deny command or
coral_pkt_atm_hook() can be used to filter by VC
before performing reassembly, for better performance.
In CoralReef 3.1 and later, FATM devices can be made to echo by
using the -C'
iomode
echo'
option to CoralReef applications, or the
CORAL_RX_ECHO
flag in the API. POINT devices
always echo, in all versions. However, the echoing will probably
not work before the firmware is loaded (which happens the first
time a coral application is used on a device), or while the card is
being reset, so we recommend not relying on echo for important
traffic.
SONET and SDH are ANSI and international standards, respectively, for synchronous data transmission on optical media. So far, we have only been able to test CoralReef and supported hardware on SONET links, and do not know if any of the cards supported are capable of handling SDH. Reading SDH instead of SONET is primarily an issue of the hardware and firmware, not CoralReef, so if the hardware and firmware support it, we expect CoralReef will too. In particular, there should be no problem getting it to work with any card that presents a native network interface which CoralReef can read via libpcap. Cards with special Coral drivers (POINT, FATM, DAG) would likely require alternate firmware to read SDH, which may or may not work with CoralReef.
High-speed POS is supported by CoralReef via drivers for the DAG cards. Other manufacturers now make capture cards that can tap POS networks and present a libpcap interface to Coralreef, although at high link utilization, the libpcap interface can cause significant packet loss. At this time, CAIDA does not have the resources to develop specialized drivers that minimize packet loss for these cards.
CoralReef supports Endace DAG cards, several of which can read GigE and 10GigE links. Additionally, there are many Gigabit Ethernet cards that can present a libpcap interface that CoralReef can read.
Coralreef reports ATM cell loss for each block in
coral_blk_info_t.cells_lost.
As of CoralReef version version 3.4,
coral_pkt_stats_t
also contains a layer 2 (ATM cell) loss counter. Be aware, however,
that these counts are for each 1MB block returned by the driver;
if you use CoralReef's intervals, the block boundaries will not be
aligned with the interval boundaries.
Because the
coral_pkt_stats_t.l2_drop
counter is updated for each 1MB block received from
the driver of the ATM capture card, block boundaries may not be
aligned with interval boundaries. As shown in the diagram below,
the cell loss for each block is reported in the first interval
contained in that block, and the cell loss for each interval is
the cell loss for every block that started (but didn't necessarily
end) in that interval. The error should be small when there
are many blocks per interval. To get more accurate cell loss rates,
you must handle them on a per-block basis, for example with
coral_cell_block_hook.
An example of cell loss reporting using intervals:
+-----------------------------------------------------------------------------+ | block 1, 3 cells lost | block 2, 2 cells lost | block 3, 4 cells lost | +------------+------------++--------------------------+-------+---------------+ | interval 1 | interval 2 | interval 3 | +-------------------------------------------------------------+ interval 1: coral_pkt_stats_t.l2_drop = 3 interval 2: coral_pkt_stats_t.l2_drop = 0 interval 3: coral_pkt_stats_t.l2_drop = 6
ATM cell loss does not contribute to the
coral_pkt_stats_t.pkts_drop
counter. This counter is used to record layer-3 packet loss on libpcap
interfaces and thus does not reflect layer-2 cell loss.