150 likes | 353 Views
NetFPGA European Developers Workshop 2010 . An Open Source Hardware Module for High-Speed Network Monitoring on NetFPGA. David J. Miller Email: <first.last>@cl.cam.ac.uk Computer Laboratory University of Cambridge. Gianni Antichi , Stefano Giordano Email: <first.last>@iet.unipi.it
E N D
NetFPGA European Developers Workshop 2010 An Open Source Hardware Module for High-Speed Network Monitoring on NetFPGA David J. Miller Email: <first.last>@cl.cam.ac.uk Computer Laboratory University of Cambridge Gianni Antichi, Stefano Giordano Email: <first.last>@iet.unipi.it Department of Information Engineering University of Pisa
Outline • Introduction • Motivations • Our solution • Hardware plane • Software plane • Results • Future work
Introduction Network measurement and monitoringhasbeenan active area ofresearchfor at least the past 15 years. Applications include academicresearch, security, and trafficengineering and management. We present a passive network measurement solution based on the low-cost NetFPGA — suitable for network research, security applications, and traffic engineering and management. • Key features: • Accurate timestamping. • Ability to filter traffic based on flow.
Motivations • The ideal measurement and monitoring solution: • Accurate. • Guarantee no loss of information (or at least records exactly where records have been lost). • Inexpensive. • Software solutions: • Cheap. • Work well for low-speed networks or when timestamp accuracy is not too important. • Don’t scale to high speed networks. • Hardware solutions: • Very accurate. • Expensive.
Motivations We use NetFPGA platform, whichis open and low-cost, toachieve the performance ofhardware-basedsolutionsbut at costsclosertothatofsoftware-onlysolutions. • In-parallel with the link to be monitored: • Copper network links require an expensive active tap. • Passive optical splitters are inexpensive. • In-line with the link to be monitored: • Cheap. • Offers possibility of building an Intrusion Prevention System. • Extra latency. • Risk of interruption of the link. In-series or In-parallel monitoring?
Our Solution (Hardware Plane) Our monitor system addstwonewmodulesto the standard NetFPGA pipeline.
Our Solution (Hardware Plane) Timestamping module: • Attaches to the RGMII as near as possible to the MAC. • The RGMII asserts its “data valid” signal when the SFD of a frame is received at a physical interface. • We sample the free-running timestamp counter on the low-to-high transition of the “data valid” signal. • Timestamps are sampled from a 64-bit, free-running counter driven by the 125 MHz system clock, which increment by 8 once every 8 ns. • The timestamp counter can be reset.
Our Solution (Hardware Plane) • Filtering module: • All packets received are retransmitted. • Packets that match one of up to 32 filter rules are also copied verbatim, with their timestamp prepended, to the host. • We use the TCAM modules available in Xilinx CoreGen. • TCAMs are fast and permit on-the-fly rule updates. • Owing to problems with timing closure, we found it necessary to implement the filter using 16-entry TCAMs, rather than one 32-entry TCAM.
Our Solution (Hardware Plane) • Pipeline: • Timestamps pass in a side channel parallel with the main packet data path.
Our Solution (Software Plane) • Auxiliary command line tool for TCAM rule management • Initialisation of the hardware timestamp • Libpcap-based capture programme: • Converts and remove the hardware timestamp. • Overwrite the PCAP timestamp. • Record a standard PCAP trace.
Results seconds • X axis: DAG behaviour. • Y axis: NetFPGA behaviour. • Comparison of the two absolute drift (1000 samples). seconds
Results milliseconds • Relative drift: Comparison between the two oscillator. • We lose 1.7 ms in 53.7 seconds (32 ppm). packets
Future Work Wepresent a flexible and cheap passive NetFPGA-basedmonitoring system. • Use of Direct Digital Synthesis, together with an external time-base to provide error-corrected timestamps in a convenient format. • Re-implementation of the flow filter using Bloom Filters in order to support substantially more than 32 flows. • Optional in-band markers for packets belonging to unmatched flows. • Refactor to include timestamp in a module-header. • Live libpcap support with extended precision timestamps • Endace ERF format and libtrace support.
from 12.eth2 to 13.nf2c0 Nf-test12 Nf-test13