Idle and Hard Timeout Support for OpenFlow
The idle timeout and a hard timeout control the removal of a flow entry from the OpenFlow table. If either value is non-zero, the switch must note the flow entry's arrival time, as it may need to evict the entry later. A non-zero idle_timeout entry field causes the flow entry to be removed after the given number of seconds if no packet has been matched by the flow. A non-zero hard_timeout field causes the flow entry to be removed after the given number of seconds, regardless of how many packets it has matched.
- Hard timeout: The absolute timeout after which the flow is removed from the device.
- Idle timeout: The absolute timeout after which the flow is removed from the device when there are no packets hitting the flow for the duration.
Idle and Hard Timeout Behavior
| Idle Timeout | Hard Timeout | Behavior |
|---|---|---|
| Non-zero | Zero | Flow entry must expire after the idle timeout seconds with no received traffic. |
| Zero | Non-zero | Flow entry must expire in hard timeout seconds regardless of whether or not packets are hitting the flow. |
| Non-zero | Non-zero | Flow entry will time out after the idle timeout seconds with no traffic, or hard timeout seconds, whichever comes first. |
| Zero | Zero | Flow entry is considered permanent and it does not time out. It can be removed with a flow table modification message of type OFPFC_DELETE. |
- The hard and idle timeout range is from 0 through 65535 seconds.
You can use the
show openflow flowscommand to view the elapsed time between the establishment of the flow and the last time it was matched. The command also shows the active flows with idle and hard timeouts.- When a flow gets deleted because of either idle or
hard timeout, a syslog is generated. You can enable or disable message with the
openflow log timeoutcommand. - When timeout values are not specified in a flow the value is displayed as zero and the flow is considered permanent until the controller specifically deletes the flow.
- If the OFPFF_SEND_FLOW_REM flag is set (in a flow sent by the controller), a flow delete message is sent to the controller.
- In case of connection interruption, the device continues to work under Fail Secure Mode.
- For modification requests (OFPFC_MODIFY or OFPFC_MODIFY_STRICT), if a matching entry exists in the table, the instructions field of this entry is updated with the value from the request; however, its cookie, idle timeout, hard timeout, flags, counters, and duration fields are left unchanged.
- Idle and hard timeouts are supported for both port-based and generic flows.
Port-Based Flows
In port-based flows, when incoming traffic does not hit the flow, the idle time starts to increment. A hit causes this time to reset. The flow duration time keeps incrementing independent of the traffic hit. Once the limit is reached for either the idle time or the flow duration, the flow is deleted and the reason for deletion (idle timeout or hard timeout) is recorded by the system.
Generic Flow
Generic flows may be installed on multiple ports, depending on the OpenFlow-enabled ports. Even if the traffic hits only on one of those in_ports, flow statistics increments. Therefore, the idle time does not increment from its zero value. When incoming traffic does not hit any of the flows, the idle time starts to increment. A hit causes this time to reset. The flow duration time keeps incrementing independent of the traffic hit. Once the limit is reached for either the idle time or the flow duration, the flow is deleted and the reason for deletion (idle timeout or hard timeout) is recorded by the system.
Timeout Limitations
The completion of the deletion of a flow in a system lags the timeout by a small amount, typically not to exceed a maximum of four minutes. The lag depends on the number of flows present in the system at that time.