-
Notifications
You must be signed in to change notification settings - Fork 192
Ofdatapath Manual
The ofdatapath is a userspace implementation of an OpenFlow datapath. It monitors one or more network device interfaces, forwarding packets between them according to the entries in the flow table that it maintains. When it is used with ofprotocol(8), to connect the datapath to an OpenFlow controller, the combination is an OpenFlow switch.
For access to network devices, the ofdatapath program must normally run as root. The mandatory method argument specifies how ofprotocol communicates with ofdatapath, as a passive OpenFlow connection method. Ordinarily method takes the following form:
- punix:file: Listens for connections on the Unix domain server socket named file.
The following method is also supported, but its use would be unusual because ofdatapath and ofprotocol should run on the same machine:
- ptcp:[port]: Listens for TCP connections from remote OpenFlow switches on port (default: 6653).
-
-i, --interfaces=netdev[,netdev]...: Specifies each netdev (e.g., eth0) as a switch port. The specified network devices should not have any configured IP addresses. This option may be given any number of times to specify additional network devices.
-
-L, --local-port=netdev: Specifies the network device to use as the userspace datapath's local port which is a network device that ofprotocol bridges to the physical switch ports for use in in-band control. When this option is not specified, the default is tap:, which causes a new TAP virtual network device to be allocated with a default name assigned by the kernel. To do the same, but assign a specific name name to the TAP net work device, specify the option as --local-port=tap:name.
Either way, the existence of TAP devices created by ofdatapath is temporary: they are destroyed when ofdatapath exits. If this is undesirable, you may use tunctl(8) to create a persistent TAP network device and then pass it to ofdatapath, like so:
-
Create a persistent TAP network device: tunctl -t mytap. (The tunctl(8) utility is part of User Mode Linux. It is not included with the OpenFlow reference implementation.)
-
Invoke ofdatapath using mytap, e.g. ofdatapath --local-port=mytap ... (Note the lack of tap: prefix on the --local-port argument.)
-
Invoke ofprotocol(8), etc., and use the switch as desired.
-
When ofprotocol and ofdatapath have terminated and the TAP network device is no longer needed, you may destroy it with: tunctl -d mytap
It does not ordinarily make sense to specify the name of a physical network device on -L or --local-port.
-
--no-local-port: Do not provide a local port as part of the datapath. When this option is used, the switch will not support in-band control.
-
--no-slicing: Disable slicing (no queue configuration to ports). When this option is used, the switch will have 0 queues, and therefore no slicing-related functionality is supported. This option is useful when run-time dependencies for slicing (tc and related kernel configuration) are not met.
-
-d, --datapath-id=dpid: Specifies the OpenFlow datapath ID (a 64-bit number that uniquely identifies a controller) as dpid, which consists of exactly 16 hex digits. Without this option, ofdatapath picks an ID randomly.
-
--multiconn: Enables support to multiple controller connections. The role election mechanism is described by the OpenFlow 1.3 specification.
-
-v, --verbose: Sets the maximum logging verbosity level, equivalent to --verbose=ANY:ANY:dbg.
-
-h, --help: Prints a brief help message to the console.
-
-V, --version: Prints version information to the console.
The userspace datapath's performance lags significantly behind that of the kernel-based switch. It should only be used when the kernel-based switch cannot be.
On Linux, general-purpose support for VLAN tag rewriting is precluded by the Linux kernel AF_PACKET implementation.