WITS: Local ISP B-I
|Trace Format||ERF, captured using a DAG 3|
|Volume on Disk||10 GB|
|Number of Traces||4|
|Capture Start (Local)||Thu Feb 24 10:45:00 2005|
|Capture End (Local)||Thu Feb 24 21:15:00 2005|
|Total Duration||0 Days, 1 Hours, 0 Minutes and 0 Seconds|
|Packets Captured||310 million|
|Total Traffic||125 GB|
|Contiguity||First 3 traces are contiguous, the last is standalone.|
|Snapping Method||Packets truncated four bytes after the end of the transport header.|
|Rotation Policy||File is rotated every 15 minutes, based on the start of the hour.|
This is a small collection of traces captured at a New Zealand ISP. Due to NDA requirements, we cannot disclose the name of the ISP, nor can we offer these traces for public download. The traces were captured using a single DAG 3 card and the WDCap trace capture software. The version of WDCap used was version 2.0.0 and the Libtrace version was 2.0.13.
This traceset should be regarded as somewhat experimental as it consists of traces taken during the deployment of the first capture point at the ISP. The traceset is very small and probably shouldn't be used for serious trace analysis - instead, we recommend using Traceset II that we captured using a similar setup.
The capture point was connected to a SPAN port on a switch that carried some, but not all, of the ISP's traffic. All the traffic that passed through that switch was captured. The location of the capture point allowed us to capture both incoming and outgoing traffic for a subset of customers. However, it appears that we only have a single direction available with this traceset and the traces contain many records that have been truncated prior to the Ethernet header. We suspect that those records are for the second direction. As a result, bidirectional flow analysis is NOT possible with these traces.
Unlike the Waikato tracesets that were also captured using WDCap, packets were captured and written to disk using a single WDCap process - there was no network export involved.
Each trace file is named using the following format: yyyymmdd-HHMMSS-[code].gz. The time and date refers to the time in UTC when the first packet in the file was captured. The code refers to the event which caused the previous file to be closed and this new file to be created.
Codes of interest for this traceset are as follows:
- 0 - Rotation boundary was reached
Regular file rotation (code 0) occurs 4 times every hour, starting at the beginning of the hour. All traces are 15 minutes in length. The traceset is not totally contiguous - the last trace in the set is a standalone 15 minute trace that was taken nearly 12 hours after the previous one.
The packets have truncated four bytes after the end of the transport header. This means each packet record will contain four bytes of user payload. ICMP packets which are truncated four bytes after any IP and transport headers that may be present in the packet payload.
The recommended method for processing these traces is to use Libtrace, which we have developed. There are a number of tools included with libtrace such as a packet dumping utility, a trace format converter (for example, to convert to pcap), a trace splitting/filtering tool and a few statistic generators. We suggest you examine the Libtrace Wiki for more details on the Libtrace tools and the library itself.
|Name||Local Start Time||Duration||Total Packets||Compressed Size|
|20050223-214500-0||Thu Feb 24 10:45:00 2005||0:15:00||69 million||2,308 MB|
|20050223-220000-0||Thu Feb 24 11:00:00 2005||0:15:00||70 million||2,328 MB|
|20050223-221500-0||Thu Feb 24 11:15:00 2005||0:15:00||71 million||2,371 MB|
|20050224-080000-0||Thu Feb 24 21:00:00 2005||0:15:00||98 million||3,247 MB|