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 in which if there are no packets hitting the flow for the duration, then flow is removed from the device.
| 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 entry. |
| Non-zero | Non-zero | Flow entry will timeout after 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.
- Use the command
show openflow flowsto see 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 command
[no] openflow log timeout. - When timeout values are not specified in a flow, its value is displayed as zero and flow is considered as permanent till controller specifically deletes this flow.
- If OFPFF_SEND_FLOW_REM flag is set (in flow sent by the controller), then flow delete message is sent to the controller.
- In case of connection interruption, 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, whereas its cookie, idle timeout, hard timeout, flags, counters, and duration fields are left unchanged.
- It is supported for both port based and generic flows.
Port-based flow
- 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, 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, hard timeout) is recorded by the system.
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.