OpenFlow Tee
This is a utility filter that sits between and OpenFlow device and the
OpenFlow controller. This filter bidirectionally passes, as is, all
traffic between the device and the controller. This filter
can be configured to tee OpenFlow packet in messages to third party
applications via Kafka
(future) and REST
as well as supports an API
(currently REST
only) to packet out messages to a switch ports.
The purpose of this utility filter is to allow the development of SDN
applications that execute outside the SDN controller processes, i.e,
that don't have to be written for a specific SDN controller such as
ONOS
or ODL
.
Quick Start
There is a sample work space github project at
http://github.com/dbainbri-ciena/oftee_workspace.
Please visit this project to see oftee
in action.
SDN Application Initialization
To utilize the OpenFlow tee the external SDN application or operator
must perform some initialization so that the OpenFlow device does a
packet in to the controller on the desired packets and the tee forwards
the desired packets to the external SDN application.
SDN Application Behavior
While the SDN application receives packet in packets from the OpenFlow
Tee, if should use the controller's API to influence an open flow device
or to emit a packet back into the open flow network. Because most SDN
controllers do not support and API to allow packet out emits to a device, this
application does support a REST
API to support the capability.
It is possible and expected for the SDN to communicate over the network
to other services or applications outside the OpenFlow network.
Application Configuration
The application is written in the style of a 12 factor application,
https://12factor.net/, and thus configured via environment variables. The
configuration information can be viewed by setting the environment variable
HELP=true
or using the --help
command line flag. This will display the
following information:
This application is configured via the environment. The following environment
variables can be used:
KEY TYPE DEFAULT REQUIRED DESCRIPTION
HELP True or False false show this message
LISTEN_ON String :8000 true connection on which to listen for an open flow device
API_ON String :8002 true port on which to listen to accept API requests
PROXY_TO String :8001 true connection on which to attach to an SDN controller
TEE_TO Comma-separated list of String list of connections on which tee packet in messages
TEE_RAW True or False false only tee raw packets to the client, openflow headers not included
LOG_LEVEL String debug logging level
SHARE_CONNECTIONS True or False true use shared connections to outbound end points
CPU_PROFILE String cpu.pprof file to which to write CPU profile data
MEM_PROFILE String mem.pprof file to which to write MEM profile data
Tee Configuration
The TEE_TO
configuration is a list of end points to which packet in messages
should be published. Each end point may include a set of match criteria
such that only packets that match the criteria will be forwarded. The format
of an individual end point configuration is:
criteria1=value1;criteria2=value2;...;action=http://remote.host:port/path
example
dl_type=0x8942;action=http://172.17.0.3:8000
Multiple end point configurations can be specified via the TEE_TO
variable
by separating each entry with a ",
" (comma).
Match Criteria
Currently, as of June 13, 2018, the following are the available match criteria:
dl_type
- Ethernet type expressed as a hexadecimal 16 bit value, i.e. 0x1234.
Action Specification
The action specification is a URL reference. Currently, as of June 13, 2018,
only http
based URLs are supported.
Proxy Configuration
The PROXY_TO
configuration is a single end point that references the SDN
controller to which oftee
should proxy OpenFlow messages. This is specified
tcp://host:port
, example, tcp://172.17.0.2:6653
Device Configuration
The oftee
sits between OpenFlow devices and the SDN controller. The oftee
is configured to proxy to the SDN controller, typically port 6653
and the
devices are configured to use the oftee
as their SDN controller. If oftee
is
listening on port 8853
on IP 172.17.0.4
then the devices would set their
controller to tcp:172.17.0.4:8853
.
API
oftee
supports five (5) REST endpoints:
/oftee
- GET
- returns a JSON
structure of the devices (DPIDs) known to oftee
/oftee/{dpid}
- POST
- used to inject an OF packet out message to a device
/oftee/profile/cpu/start
- POST
- starts a CPU profile session
/oftee/profile/cpu/stop
- POST
- completes a CPU profile session
/oftee/profile/mem
- POST
- creates a memory profile dump
Credits
I have advocated for the disaggregation of the control plane, both
in the context of ONOS and ODL. This project originated out of a conversation
with and suggestion by Sergio
revolving around the topic of controller disaggregation.