# Revision history [back]

The following shorthand notations are also available:
tcp    Same as dl_type=0x0800,nw_proto=6


I then created a flow using ovs-ofctl with the tcp shorthand. The controller picked it up, and when I used the RESTCONF API to plumb the operational store, I noticed that the controller added:

<match> <ethernet-match><ethernet-type><type>2048</type></ethernet-type></ethernet-match>

and

<ip-match><ip-protocol>6</ip-protocol></ip-match>

</match>

The following shorthand notations are also available:
tcp    Same as dl_type=0x0800,nw_proto=6


I then created a flow using ovs-ofctl ovs-ofctl with the tcp shorthand. The controller picked it up, and when I used the RESTCONF API to plumb the operational store, I noticed that the controller added:

<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>

...

<ip-match>
<ip-protocol>6</ip-protocol>
</ip-match>
</match>


So, I modified my RESCONF Call above with the following:

1. I added a section that matches on Ethertype
2. I change the IP Proto from 4 (ip) to 6 (tcp)
3. I deleted a bunch of garbage: strict, cookie_mask, installHW and barrier
4. I set the timeouts to zero.

Here is the new flow that works:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<instructions>
<instruction>
<order>0</order>
<go-to-table>
<table_id>1</table_id>
</go-to-table>
</instruction>
</instructions>
<table_id>0</table_id>
<id>256</id>
<match>
<ethernet-match><ethernet-type><type>2048</type></ethernet-type></ethernet-match>        <ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>
<ipv4-source>192.168.11.0/24</ipv4-source>
<ipv4-destination>192.168.11.0/24</ipv4-destination>
<ip-match>
<ip-protocol>6</ip-protocol>
</ip-match>
<in-port>0</in-port>
</match>
<hard-timeout>0</hard-timeout>