50.1 Introduction
Like OpenFlow, DirectFlow exposes the underlying forwarding ASICs capabilities through a programmable interface like EAPI or the standard CLI.
Unlike OpenFlow, DirectFlow works in conjunction with all other aspects of standard L2/L3 bridging or forwarding, and DirectFlow traffic is subject to the standard packet processing pipeline within the ASIC. You can think of DirectFlow as a stage in packet processing that processes traffic after ingress checks and before any egress actions.
This feature enables you to configure flows that consist of a matching criteria and actions, and to modify how traffic is processed (for example, by overriding the L2 lookup decision or rewriting a mac address or VLAN).
Features like MAC learning, STP state checks, ingress or egress VLAN membership checks on ports, ACLs, QoS and other features are all respected by DirectFlow. Traffic that doesn't match any programmed flow is processed normally while traffic that matches programmed flows is now subject to the actions specified in the flows.
DirectFlow and OpenFlow are mutually exclusive and you can run only one of the two at any given time.
How DirectFlow is different from OpenFlow
There is no default flow matching all traffic, so traffic not matched by other rules is forwarded as normal. This means the configuration/ controller/ application doesn’t consume TCAM space programming flows for normal forwarding.
DirectFlow works with other features and so the user can use ACL, rate limiting, STP etc. in their network as normal and not build all of that into the application used to inject flows.
DirectFlow flows can be configured from the CLI or using EAPI, giving users the option of using flow based forwarding without an external controller. This is especially useful where the number of flows is small and static e.g.to process a small subset of the traffic in a different manner to the normal L2/L3 pipeline.
Unlike OpenFlow which requires the switch support OUTPUT NORMAL or re-circulate a packet in order to send a packet from the OpenFlow domain to non-OpenFlow domain, there is just one domain with DirectFlow.
50.1.1 DirectFlow Flows
Similar to OpenFlow, you can define a relative priority between flows and define idle or hard timeouts for the flow. DirectFlow also enables you to insert a flow entry that matches on specified criteria, and define actions to be taken on traffic that matches the specified matching conditions. You can define flows to match on TCP flags, IPv6 source and destination addresses, input ports, and more.
For more information, see: DirectFlow Non-persistent Flows
DirectFlow enables you to configure flows that are not visible in the startup or running configurations and do not persist over a reboot. This feature is designed to be used for flows that are configured by a custom agent using the EOS SDK or eAPI and age out (expire) after a specified time period.  
For example, if you are using a custom agent that reacts to traffic sent to the CPU (the redirect to CPU action), and you want to use a flow that will drop all matching traffic for 5 minutes, the agent can program a non-persistent flow that expires after a hard timeout of 300 seconds.
Using a non-persistent flow for this purpose ensures that other administrator actions (for example, saving the configuration) do not result in the flow being resurrected on startup or reverting to the saved configuration. It also removes the need for the agent to delete the expired flow.
Note By default, all DirectFlow flows are persistent. You must use the no persistent command to configure a non-persistent flow. Supported matches
DirectFlow supports all matches supported on EOS with OpenFlow 1.0.
This includes matches on VLAN, ether type, source or destination MAC address, COS, source or destination IP address, IP protocol, IP TOS, L4 source, destination ports, ICMP type, and code.
In addition, DirectFlow also allows matching on:
TCP flags
IPv6 source address
IPv6 destination address
Traffic injected from the CPU
Input port
DirectFlow also permits re-using the same flow on multiple input ports, saving valuable TCAM space. Supported actions
DirectFlow supports all actions supported on EOS with OpenFlow 1.0, including:
Setting the source or destination MAC address
Transmit queue
Output port list and mirroring traffic pre-modification (ingress mirror) and post-modification (egress mirror).
Redirect to CPU
The redirect to CPU action is useful in cases in which a custom agent is running on EOS and you want to trap specific traffic (matching traffic) and send the trapped traffic to the agent. See the example “Redirect to CPU”.