2021-04-16-75-taps.md

pktvisor Taps

Status

Experimental: implemented and available for beta testing but the interface may still change

Summary

Taps are named, host specific connection specifications for the raw input streams accessed by pktvisord. They represent configuration data only; they do not cause any processing to take place in pktvisord. They should be referenced by Collection Policies (#76) by name.

The goal of Taps is to abstract away host level details such as ethernet interface or dnstap socket location so that collection policies can apply to a broad set of pktvisor agents without worrying about these details. It also provides for an easy way to integrate with existing configuration management stacks which will hold the source of truth for this type of information.

Taps may be configured on the command line at agent start up, and may optionally be configured by the Admin API if available.

taps.yaml

version: "1.0"

visor:
  # each tap has input module specific configuration options
  taps:
    # a pcap tap which uses eth0 and is referenced by the identifier "anycast"
    anycast:
      input_type: pcap
      config:
        iface: eth0
      tags:
        virtual: true
        vhost: 1
    # an sflow tap which listens on the given IP and port, referenced by the identifier "pop_switch"
    pop_switch:
      input_type: flow
      config:
        flow_type: sflow
        port: 6343
        bind: 192.168.1.1
      tags:
        virtual: false
        vhost: 2
    # a dnstap tap which gets its stream from the given socket, named "trex_tap"
    trex_tap:
      input_type: dnstap
      config:
        socket: /var/dns.sock

REST API

CRUD on Taps for a running pktvisord instance is possible if the Admin API is active.

/api/v1/taps

/api/v1/taps/:id:

Standalone Command Line Example

$ pktvisord --config taps.yaml