[ovs-discuss] OFPFC_DELETE and OFPFC_DELETE_STRICT commands don't delete openflow rules

Ben Pfaff blp at ovn.org
Fri Jul 16 18:10:11 UTC 2021


Thanks.

This shows that there is some important difference between what the
controller is sending and what ovs-ofctl is sending, since the message
from ovs-ofctl works and the one from the controller does not.  It would
be helpful to get OVS's idea of what it's receiving from the controller.
You can make ovs-vswitchd dump all the OpenFlow it sends and receives to
the log by turning up the log level for the "vconn" module, for example
with:

ovs-appctl vlog/set vconn

On Fri, Jul 16, 2021 at 06:37:18PM +0200, alejandro.llorens at entel.upc.edu wrote:
> Hi,
> 
> This is my flow table:
> ubuntu at bqn-vdu-redirector:~$ sudo ovs-ofctl dump-flows br2
>  cookie=0x0, duration=1295.729s, table=0, n_packets=0, n_bytes=0,
> priority=65535,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc
> actions=CONTROLLER:65535
>  cookie=0x0, duration=1243.681s, table=0, n_packets=6, n_bytes=588,
> priority=500,ip,nw_src=10.10.10.116,nw_dst=10.10.10.13 actions=output:ens6
>  cookie=0x0, duration=1238.441s, table=0, n_packets=1, n_bytes=42,
> priority=500,arp,arp_spa=10.10.10.116,arp_tpa=10.10.10.13
> actions=output:ens6
>  cookie=0x0, duration=1202.476s, table=0, n_packets=5, n_bytes=490,
> priority=500,ip,nw_src=10.10.10.139,nw_dst=10.10.10.13 actions=output:ens6
>  cookie=0x0, duration=1197.353s, table=0, n_packets=1, n_bytes=42,
> priority=500,arp,arp_spa=10.10.10.139,arp_tpa=10.10.10.13
> actions=output:ens6
>  cookie=0x0, duration=1243.680s, table=0, n_packets=17, n_bytes=1386,
> priority=500,in_port=ens6 actions=output:ens4
>  cookie=0x0, duration=1166.525s, table=0, n_packets=4, n_bytes=280,
> priority=500,in_port=ens7 actions=output:ens4
>  cookie=0x0, duration=904.379s, table=0, n_packets=0, n_bytes=0,
> priority=500,in_port=ens5 actions=output:ens4
>  cookie=0x0, duration=1295.733s, table=0, n_packets=6, n_bytes=392,
> priority=0 actions=CONTROLLER:65535
> 
> The controller sends the following message to delete the flows that match
> outport -> ens6 (openflow port 3):
> version=None,msg_type=None,msg_len=None,xid=None,OFPFlowMod(buffer_id=429496
> 7295,command=3,cookie=0,cookie_mask=0,flags=0,hard_timeout=0,idle_timeout=0,
> instructions=[],match=OFPMatch(oxm_fields={}),out_group=0,out_port=3,priorit
> y=32768,table_id=255)
> 
> After sending the previous message the flow table keeps showing the flow
> rules associated to ens6 interface. As you can see in output log, there is a
> flow_mod message coming from the controller to delete the flows. 
> ubuntu at bqn-vdu-redirector:~$ cat /var/log/cloud-init-output.log | grep
> delete
> checking whether nf_ct_delete( matches in
> /lib/modules/4.15.0-122-generic/build/include/net/netfilter/nf_conntrack.h..
> . yes
> 2021-07-16T16:07:25Z|12824|connmgr|INFO|br2<->tcp:172.27.15.215:6633: 1
> flow_mods 10 s ago (1 deletes) 
> 
> However, when executing the del-flow command in the terminal this works fine
> since the flow rules associated to ens6 were deleted as shown below.
> ubuntu at bqn-vdu-redirector:~$ sudo ovs-ofctl del-flows br2 out_port=ens6
> ubuntu at bqn-vdu-redirector:~$ sudo ovs-ofctl dump-flows br2
>  cookie=0x0, duration=1366.088s, table=0, n_packets=0, n_bytes=0,
> priority=65535,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc
> actions=CONTROLLER:65535
>  cookie=0x0, duration=1314.039s, table=0, n_packets=17, n_bytes=1386,
> priority=500,in_port=ens6 actions=output:ens4
>  cookie=0x0, duration=1236.884s, table=0, n_packets=4, n_bytes=280,
> priority=500,in_port=ens7 actions=output:ens4
>  cookie=0x0, duration=974.738s, table=0, n_packets=0, n_bytes=0,
> priority=500,in_port=ens5 actions=output:ens4
>  cookie=0x0, duration=57.213s, table=0, n_packets=0, n_bytes=0,
> idle_timeout=60, priority=0,in_port=ens4 actions=output:ens7
>  cookie=0x0, duration=1366.092s, table=0, n_packets=7, n_bytes=462,
> priority=0 actions=CONTROLLER:65535
> 
> Finally, you can see the ovsdb log with the last delete action.
> ubuntu at bqn-vdu-redirector:~$ cat /var/log/cloud-init-output.log | grep
> delete
> checking whether nf_ct_delete( matches in
> /lib/modules/4.15.0-122-generic/build/include/net/netfilter/nf_conntrack.h..
> . yes
> 2021-07-16T16:07:25Z|12824|connmgr|INFO|br2<->tcp:172.27.15.215:6633: 1
> flow_mods 10 s ago (1 deletes)
> 2021-07-16T16:18:15Z|12826|connmgr|INFO|br2<->unix#98: 1 flow_mods in the
> last 0 s (1 deletes)
> 
> I hope this information helps you to solve the problem.
> 
> Regards, 
> 
> Alejandro Llorens
> 
> -----Mensaje original-----
> De: Ben Pfaff <blp at ovn.org> 
> Enviado el: Thursday, July 15, 2021 8:05 PM
> Para: Alejandro Llorens Carrodeguas <alejandro.llorens at entel.upc.edu>
> CC: bugs at openvswitch.org; 'Irian' <irian.leyva at entel.upc.edu>; 'Cristina
> Cervelló-Pastor' <cristina at entel.upc.edu>
> Asunto: Re: [ovs-discuss] OFPFC_DELETE and OFPFC_DELETE_STRICT commands
> don't delete openflow rules
> 
> Hi.  We do test OFPFC_DELETE with out_port.  What's in your flow table and
> what is an example of a command that fails?
> 
> On Thu, Jul 15, 2021 at 12:50:50PM +0200, Alejandro Llorens Carrodeguas
> wrote:
> > Hello,
> > 
> > Thanks for your quick response.
> > 
> > In order to clarify our use case, I share the method that should 
> > delete the flows according to certain outport match.
> > Our scenario is formed by a Ryu Controller (version 4.34) and an OVS 
> > switch (version 2.15.90) that interconnect several machines. Both 
> > applications (controller and OVS switch) run in the same VM with 
> > Ubuntu Server 18.04. Our idea is to delete the existing OpenFlow rules 
> > associated to a given a port that connects a failed host.
> > As you can see in the method to delete the flows, we save the 
> > information port in a dictionary called host_ovsports where the keys 
> > are the host id and the values are the OVS ports. Thus, the controller 
> > can know the port that connects a given host.
> > 
> > def del_flow():
> >         """
> >         Delete specific flows taking into account a matching outport
> >         """
> >         outport = host_ovsports[host_id]
> >          ofproto = switch_datapath.ofproto
> >          parser = switch_datapath.ofproto_parser
> >          cmd = ofproto.OFPFC_DELETE
> >          match = parser.OFPMatch()
> >          mod = parser.OFPFlowMod(datapath= switch_datapath, 
> > table_id=ofproto.OFPTT_ALL, command=cmd, out_port=outport)
> >           switch_datapath.send_msg(mod)
> > 
> > I also attach a simplified topology of our use case and what we want to
> do.
> > If you need more information let me know.
> > We are having a similar problem to the one described in the following
> link:
> > https://ryu-devel.narkive.com/i8Kl0aFy/ryu-delete-flow-entry-basing-on
> > -prior
> > ity#post4
> > 
> > They are trying to delete a flow based on the priority and we want to 
> > do it by taking into account the outport.
> > 
> > Thank in advance.
> > 
> > Regards,
> > 
> > Alejandro Llorens
> > 
> > -----Original Message-----
> > From: Ben Pfaff <blp at ovn.org>
> > Sent: jueves, 15 de julio de 2021 1:45
> > To: Alejandro Llorens Carrodeguas <alejandro.llorens at entel.upc.edu>
> > Cc: bugs at openvswitch.org; 'Irian' <irian.leyva at entel.upc.edu>; 
> > 'Cristina Cervelló-Pastor' <cristina at entel.upc.edu>
> > Subject: Re: [ovs-discuss] OFPFC_DELETE and OFPFC_DELETE_STRICT 
> > commands don't delete openflow rules
> > 
> > On Wed, Jul 14, 2021 at 06:34:46PM +0200, Alejandro Llorens 
> > Carrodeguas
> > wrote:
> > > We’re having trouble deleting OpenFlow rules using the OFPFC_DELETE 
> > > or OFPFC_DELETE_STRICT commands that send a Ryu controller to the OVS
> switch.
> > 
> > Thanks for the report.
> > 
> > So far, you've just told us that these commands don't work for your 
> > case.  I can assure you that they do work in the cases we know about.
> > So, we will need an example or a way to reproduce the problem.  The 
> > easiest you make it for us, the easier it will be to understand the 
> > problem you're seeing and either explain why your expectations are 
> > wrong or to fix the problem.
> > 
> > 
> > --
> > El software de antivirus Avast ha analizado este correo electrónico en
> busca de virus.
> > https://www.avast.com/antivirus
> 
> 


More information about the discuss mailing list