Hardware IP Tunnels

HW IP Tunnels are used to enable Service Insertion. They are presented as virtual ports to the OpenFlow agent running on the switch. Once a tunnel is created (by the Network Protector SDN Application, for example) the OpenFlow agent is notified about the presence of the new interface. The OpenFlow agent communicates this interface as a new logical port to the SDN controller. This logical port is advertised over all OpenFlow version 1.3 instances configured on the switch.

If the OpenFlow output port action for a flow rule points to a tunnel logical port, the packets matching that flow rule are diverted to the configured tunnel endpoint via the tunnel interface.

When a frame is encapsulated and sent to the controller, the frame includes the MAC headers and the VLAN tag. Even if the original frame was not VLAN tagged, the switch VLAN tags this frame with VLAN-ID set to the incoming port’s default VLAN before encapsulating it. Since frames are encapsulated, the path that the encapsulated packet traverses must be configured with a larger MTU.

Up to 16 unique tunnel interfaces can be created to actively forward traffic.


	NOTE: Tunnels are IPv4 only. IPv6 tunnels are not supported in the current version.

Tunnel Creation

Tunnels can be created using SNMP. The switch manages tunnels, with each tunnel having a unique interface index. First the application (such as the Network Protector SDN Application) queries a switch to determine if it supports configuring tunnels. This is via an SNMP object that returns the number of tunnel interfaces supported on the switch. Once it is determined that tunnels can be configured, the controller can move on to creating the appropriate interface.

The following sequence diagram explains the process of creation of a tunnel.

Tunnel Creation

A switch management module failover results in tunnels being removed from hardware and OpenFlow rules pointing to these tunnels will drop frames.


	NOTE: Tunnel-related configuration information is nonvolatile and cannot be restored after a device reboot. The controller has to recreate the tunnel interface if the switch reboots and comes back up.

Tunnel Deletion

The application can delete the tunnel interface it created using SNMP. The switch does not check if there are any active OpenFlow rules using that tunnel but goes ahead and deletes the interface. If there are active flow rules that are using a tunnel, traffic matching those flow rules are dropped because the tunnel has been deleted.

Once a tunnel interface has been deleted, the OpenFlow agent communicates the same to the controller as a logical port removal notification. The agent does not remove any flow rules that use these virtual ports in line with the OpenFlow 1.3 Specification. The controller has to remove these flow rules or modify them appropriately.

Tunnel Aliveness check using OpenFlow

Detection of Tunnel connectivity status via OpenFlow message:

If the application does not receive any packet on the tunnel interface for a certain time, it can check for the tunnel path status. If active, by crafting a heartbeat packet and sending an OpenFlow packet OUT message to the switch with the output port for the heartbeat packet as the tunnel interface. Once the switch receives the OpenFlow message, it sends the heartbeat frame encapsulated out the tunnel interface to the application. The application can use this message to confirm that the tunnel path is working fine.

Tunnel heartbeat via OpenFlow message

OpenFlow and Service Tunnels

The switch notifies the OpenFlow controller about tunnel interface status changes (UP/DOWN) as well.

Once the controller is notified of the tunnel instance via the OpenFlow switch agent, it can use the same as a valid output port in its FLOW-MOD messages it pushes to the switch.

If the OpenFlow outport action for a flow rule points to a tunnel virtual port, the packets matching that flow rule are rerouted to the controller via the tunnel interface.

Integration with OpenFlow

OpenFlow and Service Intercept Tunnel Restrictions

A tunnel interface cannot be part of a multiport output action.
A flow-rule’s output action of sending packets to a tunnel cannot be combined with “Normal” or “SendToController” actions.
A tunnel interface cannot be part of FLOOD action.
Redirecting packets to SI tunnels on an OpenFlow 1.0 instance is not supported. Tunnels are only supported on OpenFlow 1.3 instances.
OpenFlow pipeline is bypassed for packets coming back on a tunnel. The device forwarding tables are used to determine how to forward these packets.
The switch does not remove the flows referencing tunnels when tunnel interfaces are deleted. The controller has to come back and delete those flows.
The tunnel interfaces are only supported on the Policy Engine (TCAM) tables and not with the software tables.
In the event of management card failover (on platforms with redundant management card support), tunnel interfaces are removed but OpenFlow does not delete any flows referencing tunnel interfaces. Once the application recreates those tunnels, traffic forwarding to tunnels will resume.
OpenFlow Port mod requests are not supported on tunnel interfaces.
A tunnel interface cannot be used as a match parameter in any flow programmed by the OpenFlow controller.
When using Service Insertion, VLAN interfaces that have a DHCP address and OOBM interfaces cannot be used to create a tunnel between device and the application.

OpenFlow and Service Tap Tunnel Restrictions

The OpenFlow action OutPort = Mirror tunnel is not supported for flow rules programmed on the OpenFlow software tables.
If there is a flow rule whose action is Normal + Mirror Tunnel and a packet matching that flow rule is dropped (based on its Normal action or because of a rate limit), that PKT will still be sent to the mirror tunnel.

NOTE: The Mirror action does not affect the forwarding behavior. It only mirrors what was received that matched the OpenFlow rule.
The PKT that is sent to the mirror tunnel does not have its DSCP rewritten to EF if there is an OpenFlow rule such as:
```
{match SRC.IP == abc, 
action = (DSCP = EF, OutPort = COPY Tunnel)}
```
The inbound DSCP value of the PKT is what appears as the PKT’s DSCP on the mirror tunnel.
OpenFlow port MOD requests is not supported on mirror tunnel ports.
Mirror tunnel port cannot be used as a match field (IN_PORT).
When an administrator deletes the mirror tunnel interface (via SNMP) but there are OpenFlow rules that are using those tunnels, the switch will not automatically remove flows associated with the tunnel ports even though mirroring will be stopped.

The controller has to delete those flows explicitly.
Cannot combine the outport mirror action with the Strip VLAN, Modify VLAN, Modify MAC actions.
Cannot support the outport mirror action on an OpenFlow 1.0 instance.
OpenFlow groups cannot support output mirror as an action.

Service Tunnel restrictions with other features

Multicast routing cannot be enabled on a device when Service Tunnels are configured and vice-versa.
Distributed trunking cannot be configured on a device when Service Tunnels are configured and vice-versa.
MESH cannot be configured on a device when Service Tunnels are configured and vice-versa.
MAC-Mirror cannot be configured on a device when Service Tunnels are configured and vice-versa.
QinQ cannot be configured on a device when Service Tunnels are configured and vice-versa.

prev	up	next
Service Insertion	home	CLI commands


	NOTE: The `Mirror` action does not affect the forwarding behavior. It only mirrors what was received that matched the OpenFlow rule.