Re: [Ryu-devel] Unable to send packet out message

2018-03-28 Thread Iwase Yusuke 

Hi,

If you are using OpenFlow 1.5, please confirm your OVS supports OpenFlow 1.5.
Only some newer version of OVS support OpenFlow 1.5 (some OpenFlow 1.5 features
seems not be supported yet though).
You can test the support status by checking whether
  $ ryu-manager ryu/app/simple_switch_15.py --verbose
can transfer "ping" packets between your hosts or not.

With OVS version 2.9.0, I can send Packet-Out with the following code.

$ git diff
diff --git a/ryu/app/simple_switch_15.py b/ryu/app/simple_switch_15.py
index 6a86ba7..f3503bf 100644
--- a/ryu/app/simple_switch_15.py
+++ b/ryu/app/simple_switch_15.py
@@ -21,6 +21,9 @@ from ryu.ofproto import ofproto_v1_5
 from ryu.lib.packet import packet
 from ryu.lib.packet import ethernet
 from ryu.lib.packet import ether_types
+from ryu.lib.packet import ipv4
+from ryu.lib.packet import in_proto
+from ryu.lib.packet import tcp


 class SimpleSwitch15(app_manager.RyuApp):
@@ -48,6 +51,39 @@ class SimpleSwitch15(app_manager.RyuApp):
   ofproto.OFPCML_NO_BUFFER)]
 self.add_flow(datapath, 0, match, actions)

+actions_out = [parser.OFPActionOutput(1)]
+pkt = packet.Packet()
+pkt.add_protocol(
+ethernet.ethernet(
+dst='08:2e:5f:2f:70:e2',
+src='d4:85:64:17:ea:15',
+ethertype=ether_types.ETH_TYPE_IP,
+)
+)
+pkt.add_protocol(
+ipv4.ipv4(
+dst='192.168.1.1',
+src='192.168.1.2',
+proto=in_proto.IPPROTO_TCP,
+)
+)
+pkt.add_protocol(
+tcp.tcp(
+src_port=50001,
+dst_port=50002,
+)
+)
+pkt.add_protocol(
+b'foobar'
+)
+pkt.serialize()
+match_out = parser.OFPMatch(in_port=2)
+out = parser.OFPPacketOut(
+datapath=datapath,
+buffer_id=ofproto.OFP_NO_BUFFER,
+match=match_out, actions=actions_out, data=pkt.data)
+datapath.send_msg(out)
+
 def add_flow(self, datapath, priority, match, actions):
 ofproto = datapath.ofproto
 parser = datapath.ofproto_parser


Thanks,
Iwase


On 2018年03月29日 02:30, Alvaro Jimenez Moreno wrote:

Hi Iwase, thanks for your response,

Im using OpenFlow 1.5. I tried to create an ethernet packet as you mentioned but 
no packet is sent by the switch. I dont really know what im doing wrong. I just 
want to send a packet from datapath_id == 233669375027733 to datapath_id == 
8995258462434.  Here's the code with the ethernet frame and header:


  @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
     def switch_features_handler(self, ev):
         msg = ev.msg
         datapath = msg.datapath
         ofproto = datapath.ofproto
         parser = datapath.ofproto_parser

         match_miss = parser.OFPMatch()
         actions_miss = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                                ofproto.OFPCML_NO_BUFFER)]
         self.add_flow(datapath, 0, match_miss, actions_miss)

         actions_out = [parser.OFPActionOutput(1)]
         #self.add_flow(datapath, 1, match_2, actions_out)
         if msg.datapath_id == 233669375027733:
             match_cpd = parser.OFPMatch(in_port=1, eth_dst='08:2e:5f:2f:70:e2', 
eth_src='d4:85:64:17:ea:15',)

             self.add_flow(datapath, 1, match_cpd, actions_out)
         elif msg.datapath_id == 8995258462434:
             match_srem = parser.OFPMatch(in_port=1, 
eth_dst='d4:85:64:17:ea:15', eth_src='08:2e:5f:2f:70:e2')

             actions_srem = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                                    ofproto.OFPCML_NO_BUFFER)]
             self.add_flow(datapath, 1, match_srem, actions_srem)
         #I just send the packet from datapath_id == 233669375027733
         if msg.datapath_id == 233669375027733:
             p = packet.Packet()
             eth = ethernet.ethernet(dst='08:2e:5f:2f:70:e2', 
src='d4:85:64:17:ea:15', ethertype=0x0800)

             p.add_protocol(eth)
             p.serialize()
             match_out = parser.OFPMatch(in_port=1)
             out = parser.OFPPacketOut(datapath=msg.datapath,
                                     buffer_id=ofproto.OFP_NO_BUFFER,
                                     match=match_out, actions=actions_out, 
data=p.data)

             datapath.send_msg(out)


Thanks in advance.


2018-03-23 0:29 GMT+01:00 Iwase Yusuke >:


Hi Alvaro,

According to the OpenFlow Spec 1.3, the data field of OFPPacketOut must be 
an
Ethernet frame and I think you need to add also Ethernet header using
"ethernet.ethernet" class.

http://osrg.github.io/ryu-book/en/html/packet_lib.html#generation-of-packets-serialization

Re: [Ryu-devel] Spliting flows through two ports

2018-03-28 Thread Iwase Yusuke 

Hi Carlos,

The group entries are looked up (or specified) by OFPActionGroup in flow
entries.

If looked up, ref_count, packet_count and byte_count should be incremented.

mininet> sh ovs-ofctl dump-group-stats s1 -O OpenFlow13
OFPST_GROUP reply (OF1.3) (xid=0x4):
group_id=1,duration=45.105s,ref_count=1,packet_count=5,byte_count=378,bucket0:packet_count=4,byte_count=336,bucket1:packet_count=1,byte_count=42

Thanks,
Iwase


On 2018年03月27日 23:10, Jose Carlos Ferreira de Melo Junior wrote:

Hi Iwase,

The group entry is added...















but I don't understand how can be looked up.
I don't know how to do this


Is there any other thing that I am missing 


thanks in advanced







2018-03-26 20:28 GMT-03:00 Iwase Yusuke >:


Hi Carlos,

 >  "*/using the group table with openflow 1.3 with no sucess/*" means that 
I am
> using the group table as i said before and it is not working, means that 
I am
> using the group specification and it doens't work.

"Does not work" means
  - no group entry added
  - group entry exists, but not looked up
  - group entry looked up, but packets are not outputted
  or ...
which you mean?


> and about your topology: It has only 2 switches or 4???

Only 2 switches (s1 and s2), which corresponding to "Start" and "End" 
switches
on the image you attached on your previous mail. Also h1 and h2 represents 
hosts
which do ping.


Thanks,
Iwase

On 2018年03月26日 21:14, Jose Carlos Ferreira de Melo Junior wrote:

Hey Iwase,

   "*/using the group table with openflow 1.3 with no sucess/*" means
that I am using the group table as i said before and it is not working,
means that I am using the group specification and it doens't work.

and about your topology: It has only 2 switches or 4???

i don't know if my code is right or if i am missing something else.




2018-03-25 21:40 GMT-03:00 Iwase Yusuke  >>:


     Hi Carlos,

     For such purpose, OFPGT_SELECT is appropriate, I guess.

     With the topology;

                    ++             ++
                    |   s1   |             |   s2   |
     ++        |      (port 2)---(port 2)      |        ++
     | h1 |---(port 1)      |             |      (port 1)---| h2 |
     ++        |      (port 3)---(port 3)      |        ++
                    |        |             |        |
                    ++             ++


     I can install groups and flows entries, then can ping between h1
and h2 with the
     following app.


     $ git diff
     diff --git a/ryu/app/simple_switch_13.py 
b/ryu/app/simple_switch_13.py
     index 06a5d0e..e1a5c3b 100644
     --- a/ryu/app/simple_switch_13.py
     +++ b/ryu/app/simple_switch_13.py
     @@ -48,6 +48,30 @@ class SimpleSwitch13(app_manager.RyuApp):
                                                 
ofproto.OFPCML_NO_BUFFER)]
               self.add_flow(datapath, 0, match, actions)

     +        buckets = [
     +            parser.OFPBucket(
     +                50, ofproto.OFPP_ANY, ofproto.OFPG_ANY,
     +                [parser.OFPActionOutput(2)]),
     +            parser.OFPBucket(
     +                50, ofproto.OFPP_ANY, ofproto.OFPG_ANY,
     +                [parser.OFPActionOutput(3)]),
     +        ]
     +        mod = parser.OFPGroupMod(
     +            datapath, ofproto.OFPGC_ADD, ofproto.OFPGT_SELECT, 1,
buckets)
     +        datapath.send_msg(mod)
     +
     +        match = parser.OFPMatch(in_port=1)
     +        actions = [parser.OFPActionGroup(1)]  # from host to 
switch
     +        self.add_flow(datapath, 1, match, actions)
     +
     +        match = parser.OFPMatch(in_port=2)
     +        actions = [parser.OFPActionOutput(1)]  # from switch to 
host
     +        self.add_flow(datapath, 1, match, actions)
     +
     +        match = parser.OFPMatch(in_port=3)
     +        actions = [parser.OFPActionOutput(1)]  # from switch to 
host
     +        self.add_flow(datapath, 1, match, actions)
     +
           def add_flow(self, datapath, priority, match, actions,
buffer_id=None):
               ofproto = datapath.ofproto
               parser = datapath.ofproto_parser


     I don't know what "using the group table with openflow 1.3 with no
sucess"
     means, but please

Re: [Ryu-devel] ryu freeze when ryu picks up segment packet

2018-03-28 Thread Takayoshi Hirasawa 
Fujimoto-san

Thank you for your patch.
I tried it and confirmed improvement of ryu's behavior.

This behavior may cause switch fabric down by external attack packet made by 
openflow channel, but does this patch apply to Ryu original script?

Thank you,
Hirasawa

--
Takayoshi Hirasawa
NTT NS Lab.
Tel: 0422-59-7294 / Fax: 0422-59-4656
Email: hirasawa.takayo...@lab.ntt.co.jp
 : takayoshi.hirasawa...@hco.ntt.co.jp
-^-^--


> -Original Message-
> From: Fujimoto Satoshi [mailto:satoshi.fujimo...@gmail.com]
> Sent: Tuesday, March 06, 2018 11:48 AM
> To: hirasawa.takayo...@lab.ntt.co.jp
> Cc: ryu-devel@lists.sourceforge.net
> Subject: Re: [Ryu-devel] ryu freeze when ryu picks up segment packet
> 
> Hi, Hirasawa-san
> 
> Sorry for late reply.
> 
> In parsing OpenFlow packets,
> Ryu checks its TCP header and predicts like that "this packet contains
> OpenFlow data".
> 
> However, if these packets are segmented, succeeding body does not have
> OpenFlow header, it has only segmented OpenFlow body.
> Then, Ryu tries to parse OpenFlow header for that body.
> This is the cause of the problem.
> 
> I wrote the patch to cease parsing when the result of parsing for header
> is invalid.
> Could you try this?
> 
> 
> diff --git a/ryu/lib/packet/openflow.py b/ryu/lib/packet/openflow.py
> index e211994..2d4a0d9 100644
> --- a/ryu/lib/packet/openflow.py
> +++ b/ryu/lib/packet/openflow.py
> @@ -46,6 +46,8 @@ class openflow(packet_base.PacketBase):
>   from ryu.ofproto import ofproto_protocol
> 
>   (version, msg_type, msg_len, xid) = ofproto_parser.header(buf)
> +if version not in ofproto_protocol._versions or msg_len !=
> len(buf):
> +raise struct.error
> 
>   msg_parser = ofproto_parser._MSG_PARSERS.get(version)
>   if msg_parser is None:
> 
> 
> Thanks,
> Fujimoto
> 
> On 2018年02月15日 20:04, Takayoshi Hirasawa wrote:
> > Fujimoto-san
> >
> > Sorry for my late reply.
> >
> >> I send the script which we use to debug Ryu packet library.
> >> Could you try this script? If this causes errors, there is something
> >> wrong with Ryu in your environment.
> >>  $ python display_pcap.py ryu-ovs-loopback.pcap
> > => I tried this script and confirmed that there is no errors.
> >
> >> * Could you tell me which version of Ryu you are using?
> > => I used ryu 4.20.
> >
> >> * Could you confirm that any traceback was logged by Ryu?
> > => Sorry, I didn’t know what I should check.
> > When ryu picks up segment packet and hung up, no log message is
> displayed
> > on the terminal.
> > Could you tell me if there are checkpoints concerning ryu behavior?
> >
> > Thank you,
> > hirasawa
> >
> > --
> > Takayoshi Hirasawa
> > NTT NS Lab.
> > Tel: 0422-59-7294 / Fax: 0422-59-4656
> > Email: hirasawa.takayo...@lab.ntt.co.jp
> >   : takayoshi.hirasawa...@hco.ntt.co.jp
> > -^-^--
> >
> >
> >> -Original Message-
> >> From: Fujimoto Satoshi [mailto:satoshi.fujimo...@gmail.com]
> >> Sent: Monday, December 04, 2017 4:19 PM
> >> To: cmdcr...@gmail.com; ryu-devel@lists.sourceforge.net
> >> Subject: Re: [Ryu-devel] ryu freeze when ryu picks up segment packet
> >>
> >> Hi, Hirasawa-san
> >>
> >> I've found that it's hard to reproduce your situation.
> >> In my environment, Packet-in including segmented packets did not cause
> >> any problem.
> >>
> >> I send the script which we use to debug Ryu packet library.
> >> Could you try this script? If this causes errors, there is something
> >> wrong with Ryu in your environment.
> >>  $ python display_pcap.py ryu-ovs-loopback.pcap
> >>
> >> And...
> >> * Could you tell me which version of Ryu you are using?
> >> * Could you confirm that any traceback was logged by Ryu?
> >>
> >>
> >> Thanks,
> >> Fujimoto
> >>
> >>
> >> On 2017年11月30日 13:49, Takayoshi Hirasawa wrote:
> >>
> >>
> >>Hi, Fujimoto-san
> >>
> >>Thank you for your reply.
> >>
> >>I attached three capture data, interface of VM which onos is running
> >> on, loopback interface of  VM which ryu & ryu-ovs is runnning on and
> >> interface of VM which onos-ovs is running on.
> >>
> >>we could confirm onos's request "OFPT_MULTIPART_REQUEST" to
> onos-ovs
> >> (onos-vm-interface:No.50, ryu-ovs-loopback:No.137,
> >> onosovs-vm-interface:No.61,) but we could not confirm onos-ovs's reply
> >> "OFPT_MULTIPART_REPLY" at onos VM
> >> interface(onosovs-vm-interface:No.62-64,
> >> ryu-ovs-loopback:No.142,143,145,146,148.)  Reply-packet seems to be
> >> picked up to ryu as packet-in operation, but ryu seems not to release
> it.
> >>
> >>this behavior is always observed when ryu pick up the segmented
> >> packet. when i changed mtu of ryu VM's interface, this
> >> behavior was observed too by the other smaller packet than the above
> >> big packet  which onos-ovs output.
> >>
> >>(i'm sorry if

Re: [Ryu-devel] Unable to send packet out message

2018-03-28 Thread Alvaro Jimenez Moreno 
Hi Iwase, thanks for your response,

Im using OpenFlow 1.5. I tried to create an ethernet packet as you
mentioned but no packet is sent by the switch. I dont really know what im
doing wrong. I just want to send a packet from datapath_id ==
233669375027733 to datapath_id == 8995258462434.  Here's the code with the
ethernet frame and header:

 @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
def switch_features_handler(self, ev):
msg = ev.msg
datapath = msg.datapath
ofproto = datapath.ofproto
parser = datapath.ofproto_parser

match_miss = parser.OFPMatch()
actions_miss = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
   ofproto.OFPCML_NO_BUFFER)]
self.add_flow(datapath, 0, match_miss, actions_miss)

actions_out = [parser.OFPActionOutput(1)]
#self.add_flow(datapath, 1, match_2, actions_out)
if msg.datapath_id == 233669375027733:
match_cpd = parser.OFPMatch(in_port=1,
eth_dst='08:2e:5f:2f:70:e2', eth_src='d4:85:64:17:ea:15',)
self.add_flow(datapath, 1, match_cpd, actions_out)
elif msg.datapath_id == 8995258462434:
match_srem = parser.OFPMatch(in_port=1,
eth_dst='d4:85:64:17:ea:15', eth_src='08:2e:5f:2f:70:e2')
actions_srem = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,

 ofproto.OFPCML_NO_BUFFER)]
self.add_flow(datapath, 1, match_srem, actions_srem)

#I just send the packet from  datapath_id == 233669375027733
if msg.datapath_id == 233669375027733:
p = packet.Packet()
eth = ethernet.ethernet(dst='08:2e:5f:2f:70:e2',
src='d4:85:64:17:ea:15', ethertype=0x0800)
p.add_protocol(eth)
p.serialize()
match_out = parser.OFPMatch(in_port=1)
out = parser.OFPPacketOut(datapath=msg.datapath,
buffer_id=ofproto.OFP_NO_BUFFER,
match=match_out, actions=actions_out,
data=p.data)
datapath.send_msg(out)


Thanks in advance.


2018-03-23 0:29 GMT+01:00 Iwase Yusuke :

> Hi Alvaro,
>
> According to the OpenFlow Spec 1.3, the data field of OFPPacketOut must be
> an
> Ethernet frame and I think you need to add also Ethernet header using
> "ethernet.ethernet" class.
> http://osrg.github.io/ryu-book/en/html/packet_lib.html#gener
> ation-of-packets-serialization
>
> > p = packet.Packet()
> > ip = ipv4.ipv4(src='172.16.10.10', dst='172.16.10.20')
> > p.add_protocol(ip)
> > p.serialize()
>
> From your code, you seems to add only IPv4 header and no Ethernet header.
>
> Thanks,
> Iwase
>
>
>
> On 2018年03月23日 01:22, Alvaro Jimenez Moreno wrote:
>
>>
>> Hi, Im having some issues to send a packet out message between 2 ovs. Im
>> have 3 PCs. 2 of them act like an ovs and the third one has the Ryu
>> controller. Im have a vlan (vid=44) por signal traffic between both ovs and
>> the controller and a vlan (vid=10) just for transport between both ovs. I
>> also have the 3 PCs physically connected by a Cisco Catalyst 2960 switch.
>> Im figuring out how to send a packet out from one ovs (172.16.10.10) to the
>> other ovs (172.16.10.20) without receiving a packet in message first. Now
>> im sending the packet out in the switch features handler as follows:
>>
>> Switch features handler:
>>
>> @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
>> def switch_features_handler(self, ev):
>> msg = ev.msg
>> datapath = msg.datapath
>> ofproto = datapath.ofproto
>> parser = datapath.ofproto_parser
>>
>> match_miss = parser.OFPMatch()
>> actions_miss = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
>> ofproto.OFPCML_NO_BUFFER)]
>>
>> self.add_flow(datapath, 0, match_miss, actions_miss)
>> match_2 = parser.OFPMatch(in_port=1, eth_type=0x800,
>> ipv4_dst='172.16.10.20')
>>
>> actions_out = [parser.OFPActionOutput(port=1)]
>> self.add_flow(datapath, 1, match_2, actions_out)
>>
>> #I send the packet out just from one ovs:
>> if msg.datapath_id == 233669375027733:
>> p = packet.Packet()
>> ip = ipv4.ipv4(src='172.16.10.10', dst='172.16.10.20')
>> p.add_protocol(ip)
>> p.serialize()
>> match_out = parser.OFPMatch(in_port=1)
>> out = parser.OFPPacketOut(datapath=msg.datapath,
>> buffer_id=ofproto.OFP_NO_BUFFER,
>> match=match_out, actions=actions_out, data=p.data)
>> datapath.send_msg(out)
>>
>> def add_flow(self, datapath, priority, match, actions):
>> ofproto = datapath.ofproto
>> parser = datapath.ofproto_parser
>>
>> inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
>> actions)]
>>
>> mod = parser.OFPFlowMod(datapath=datapath, priority=priority,
>> match=match, instructions=inst)
>> datapath.send_msg(mod)
>>
>> Packet in handler:
>>
>> @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
>> def packet_in_handler(self, ev):
>> msg = ev.msg
>> dp = msg.datapath
>> ofp = dp.ofproto
>>
>> if msg.reason ==

Re: [Ryu-devel] [PATCH] ofproto: add Nicira extension ct_clear action

2018-03-28 Thread FUJITA Tomonori 
On Wed, 28 Mar 2018 16:48:34 +0900
IWAMOTO Toshihiro  wrote:

> Signed-off-by: IWAMOTO Toshihiro 
> ---
>  ryu/lib/ofctl_string.py|   4 ++
>  ryu/ofproto/nicira_ext.py  |   1 +
>  ryu/ofproto/nx_actions.py  |  38 ++
>  .../of13/ovs-ofctl-of13-action_ct_clear.packet | Bin 0 -> 96 bytes
>  ryu/tests/packet_data_generator3/gen.py|   7 +++
>  .../ovs-ofctl-of13-action_ct_clear.packet.json |  55 
> +
>  6 files changed, 105 insertions(+)
>  create mode 100644 
> ryu/tests/packet_data/of13/ovs-ofctl-of13-action_ct_clear.packet
>  create mode 100644 
> ryu/tests/unit/ofproto/json/of13/ovs-ofctl-of13-action_ct_clear.packet.json

Applied, thanks.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel

[Ryu-devel] [PATCH] ofproto: add Nicira extension ct_clear action

2018-03-28 Thread IWAMOTO Toshihiro 
Signed-off-by: IWAMOTO Toshihiro 
---
 ryu/lib/ofctl_string.py|   4 ++
 ryu/ofproto/nicira_ext.py  |   1 +
 ryu/ofproto/nx_actions.py  |  38 ++
 .../of13/ovs-ofctl-of13-action_ct_clear.packet | Bin 0 -> 96 bytes
 ryu/tests/packet_data_generator3/gen.py|   7 +++
 .../ovs-ofctl-of13-action_ct_clear.packet.json |  55 +
 6 files changed, 105 insertions(+)
 create mode 100644 
ryu/tests/packet_data/of13/ovs-ofctl-of13-action_ct_clear.packet
 create mode 100644 
ryu/tests/unit/ofproto/json/of13/ovs-ofctl-of13-action_ct_clear.packet.json

diff --git a/ryu/lib/ofctl_string.py b/ryu/lib/ofctl_string.py
index 06a91af2..30394c65 100644
--- a/ryu/lib/ofctl_string.py
+++ b/ryu/lib/ofctl_string.py
@@ -322,3 +322,7 @@ class OfctlActionConverter(object):
 'recirc_table': recirc_table,
 'alg': alg,
 'actions': ct_actions})
+
+@classmethod
+def ct_clear(cls, ofproto, action_str):
+return dict(NXActionCTClear={})
diff --git a/ryu/ofproto/nicira_ext.py b/ryu/ofproto/nicira_ext.py
index 4a06b647..73297cfb 100644
--- a/ryu/ofproto/nicira_ext.py
+++ b/ryu/ofproto/nicira_ext.py
@@ -62,6 +62,7 @@ NXAST_NAT = 36
 NXAST_CONTROLLER2 = 37
 NXAST_SAMPLE2 = 38
 NXAST_OUTPUT_TRUNC = 39
+NXAST_CT_CLEAR = 43
 NXAST_DEC_NSH_TTL = 48
 
 NX_ACTION_RESUBMIT_PACK_STR = '!HHIHHB3x'
diff --git a/ryu/ofproto/nx_actions.py b/ryu/ofproto/nx_actions.py
index 18dc9210..ae5c48f4 100644
--- a/ryu/ofproto/nx_actions.py
+++ b/ryu/ofproto/nx_actions.py
@@ -2766,6 +2766,43 @@ def generate(ofp_name, ofpp_name):
 a.serialize(data, len(data))
 return data
 
+class NXActionCTClear(NXAction):
+"""
+Clear connection tracking state action
+
+This action clears connection tracking state from packets.
+
+And equivalent to the followings action of ovs-ofctl command.
+
+..
+  ct_clear
+..
+
++--+
+| **ct_clear** |
++--+
+
+Example::
+
+actions += [parser.NXActionCTClear()]
+"""
+_subtype = nicira_ext.NXAST_CT_CLEAR
+
+_fmt_str = '!6x'
+
+def __init__(self,
+ type_=None, len_=None, experimenter=None, subtype=None):
+super(NXActionCTClear, self).__init__()
+
+@classmethod
+def parser(cls, buf):
+return cls()
+
+def serialize_body(self):
+data = bytearray()
+msg_pack_into(self._fmt_str, data, 0)
+return data
+
 class NXActionNAT(NXAction):
 """
 Network address translation action
@@ -3061,6 +3098,7 @@ def generate(ofp_name, ofpp_name):
 'NXActionBundle',
 'NXActionBundleLoad',
 'NXActionCT',
+'NXActionCTClear',
 'NXActionNAT',
 'NXActionOutputTrunc',
 '_NXFlowSpec',  # exported for testing
diff --git a/ryu/tests/packet_data/of13/ovs-ofctl-of13-action_ct_clear.packet 
b/ryu/tests/packet_data/of13/ovs-ofctl-of13-action_ct_clear.packet
new file mode 100644
index 
..13bc390177cca46df2f76f0d5a0b54152620a94e
GIT binary patch
literal 96
zcmZSKV@P1Y0+_*K4GjO009c5TL9Bs+i;07Qf$=hsU{HW!76u8B{Qv(90t^hw3JlsH
H9s>gaa8(gW

literal 0
HcmV?d1

diff --git a/ryu/tests/packet_data_generator3/gen.py 
b/ryu/tests/packet_data_generator3/gen.py
index 0216dc42..dca45cf9 100644
--- a/ryu/tests/packet_data_generator3/gen.py
+++ b/ryu/tests/packet_data_generator3/gen.py
@@ -131,6 +131,13 @@ MESSAGES = [
'importance=39032'] +
   ['dl_type=0x86dd'] +
   ['actions=ct(commit,nat(dst=2001:1::1-2001:1::)'])},
+{'name': 'action_ct_clear',
+ 'versions': [4],
+ 'cmd': 'add-flow',
+ 'args': (['table=3,',
+   'importance=39032'] +
+  ['dl_type=0x0800,ct_state=+trk'] +
+  ['actions=ct_clear'])},
 {'name': 'action_note',
  'versions': [4],
  'cmd': 'add-flow',
diff --git 
a/ryu/tests/unit/ofproto/json/of13/ovs-ofctl-of13-action_ct_clear.packet.json 
b/ryu/tests/unit/ofproto/json/of13/ovs-ofctl-of13-action_ct_clear.packet.json
new file mode 100644
index ..32b88b72
--- /dev/null
+++ 
b/ryu/tests/unit/ofproto/json/of13/ovs-ofctl-of13-action_ct_clear.packet.json
@@ -0,0 +1,55 @@
+{
+   "OFPFlowMod": {
+  "buffer_id": 4294967295, 
+  "command": 0, 
+  "cookie": 0, 
+  "cookie_mask": 0, 
+  "flags": 0, 
+  "hard_timeout": 0, 
+  "idle_timeout": 0, 
+  "instructions": [
+ {
+"OFPInstructionActions": {
+   "actions": [
+  {
+ "NXActionCTClear": {
+"experimenter": 8992, 
+"len": 16, 
+