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.llor...@entel.upc.edu wrote: > Hi, > > This is my flow table: > ubuntu@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@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@bqn-vdu-redirector:~$ sudo ovs-ofctl del-flows br2 out_port=ens6 > ubuntu@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@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 <b...@ovn.org> > Enviado el: Thursday, July 15, 2021 8:05 PM > Para: Alejandro Llorens Carrodeguas <alejandro.llor...@entel.upc.edu> > CC: b...@openvswitch.org; 'Irian' <irian.le...@entel.upc.edu>; 'Cristina > Cervelló-Pastor' <crist...@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 <b...@ovn.org> > > Sent: jueves, 15 de julio de 2021 1:45 > > To: Alejandro Llorens Carrodeguas <alejandro.llor...@entel.upc.edu> > > Cc: b...@openvswitch.org; 'Irian' <irian.le...@entel.upc.edu>; > > 'Cristina Cervelló-Pastor' <crist...@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: > > > Were 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 > > _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss