OpenFlow interaction

OpenFlow agent on the switch will communicate VXLAN tunnel virtual port add/remove notifications to the controller.

Cannot add multiple VXLAN tunnel interfaces as part of multi-port action.

Tunnel virtual port up/down notifications will be communicated to the controller.

Cannot group VXLAN tunnels and physical ports as part of multi-port action.

Tunnel virtual port counters (TX/RX packets) will be supported via OpenFlow multipart message.

Cannot group outport "Tunnel" action with outport "Normal" or outport "SendToController" actions.

In OpenFlow virtualized mode, only OpenFlow version1.3 instances of the Overlay VLAN will advertise VXLAN virtual ports to the controller.

Cannot group outport "Tunnel" action with Strip VLAN, Modify VLAN, Modify MAC actions.

The VNI corresponding to the Overlay VLAN needs to be associated with the VXLAN tunnel for it to be advertised as a member interface of that instance.

Cannot support re-directing PKTs to VXLAN tunnels on an OpenFlow v1.0 instance. Tunnels will only be supported on OpenFlow v1.3 instances.

In OpenFlow aggregate mode, an OpenFlow rule that has a VXLAN tunnel as an outport will be allowed only if the in_vlan is an overlay VLAN and its VNI is associated with the VXLAN tunnel.

The solution does not support OpenFlow lookup on frames coming in on a VXLAN tunnel. These PKTs will be forwarded as "normal" using the switch L2/L3 forwarding table entries.

OpenFlow meters can be attached to rules that point to tunnels as output ports and metering action will work as designed.

When tunnel interfaces are deleted by the administrator and there are OpenFlow rules that are pointing to those tunnels, the switch will not automatically remove flows associated with the tunnel ports. The controller has to delete those flows explicitly.

VXLAN tunnel interfaces will be part of an OpenFlow VLAN FLOOD action.

The send-to-tunnel outport action would be supported only on the Policy Engine (TCAM) tables and not on the OpenFlow software tables.

OpenFlow modify VLAN PCP/IP DSCP action will be supported with tunnel as output port. This action will modify the payload’s DSCP field before it’s encapsulated.

OpenFlow Port MOD requests will not be supported on tunnel ports.

PKT_OUT action will be supported on tunnel port.

Tunnel Port cannot be used as a match field (IN_PORT).

All controllers connected to an OpenFlow instance running version 1.3 will receive the tunnel notifications irrespective of their roles (master/slave/equal).

If IP routing is enabled on the device and there is frame that the ASIC is L3 forwarding, OpenFlow rule that matches this frame with an outport of a VXLAN tunnel will encapsulate the IP routed version of the frame (MAC, VLAN and TTL fields modified). If ASIC punts this frame to software for an L3 table lookup miss, software should forward IP routed version of the frame to the tunnel after destination is resolved.

VXLAN tunnels are HA synced to the SMM and will continue to function after a failover. OpenFlow rules that are pointing to VXLAN tunnels will continue to forward frames to tunnels even after an HA failover.

Coexistence with SI — If an L2/L3 lookup for a frame points to a VXLAN tunnel it is possible to deflect this frame to an SI tunnel via an OpenFlow rule. Upon receiving this frame back on the SI tunnel (Sentinel validated), an L2/L3 re-lookup will result in the frame being sent out via the VXLAN tunnel interface. Note that frames coming in on tunnel interfaces (SI and VXLAN) will bypass OpenFlow lookups. OpenFlow redirect to VXLAN tunnels will not disturb the copy-CPU flags that are also set for the frame. This is so that OpenFlow/VXLAN can work in hybrid network set ups where other features like port-sec and sflow are enabled along with OpenFlow.

OpenFlow redirect to VXLAN tunnels will not override a drop action set by some other lookup in the system. If OpenFlow action conflicts with a device feature’s action (OF action is FWD and Feature XYZ’s action is COPY/DROP), both actions will fail.