[ovs-discuss] GRE remote-IP address being a multicast address

2021-06-15 Thread Shukri George Abdallah 
Why for an OVS GRE Tunnel the  remote-ip address (The tunnel destination 
address) cannot be a multicast address?

thanks

Shukri George Abdallah
Lead Network Researcher
L110 - Infra & Networking Innovation Center
Office - (703) 983-2470
Cell- (703) 282-0152
Mail Stop - J500
MITRE | Solving Problems for a Safer World(tm)

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Patch for PACKET_OUT getting deleted twice crash

2021-06-15 Thread Ilya Maximets 
On 6/15/21 4:31 AM, Tony van der Peet wrote:
> I did the patch as suggested, and it looks something like this:
> 
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -4168,9 +4168,13 @@dpif_netdev_execute(struct dpif *dpif, struct 
> dpif_execute *execute)
>    flow_hash_5tuple(execute->flow, 0));
> }
>  
> +    /* We are not losing the original packet, just relying on its previous
> + * owner to properly dispose of it.
> + */
> +    execute->packet = dp_packet_clone(execute->packet);

You're leaking the packet here and destroying the copy later, because
dp_netdev_execute_actions() steals it, so no packet left at all.
'execute->packet' should stay as is, cloned packet should be added to
the 'pp' batch.  Something like:

dp_packet_batch_init_packet(, dp_packet_clone(execute->packet));


> dp_packet_batch_init_packet(, execute->packet);
> -    pp.do_not_steal = true;
> -    dp_netdev_execute_actions(pmd, , false, execute->flow,
> +    pp.do_not_steal = false;
> +    dp_netdev_execute_actions(pmd, , true, execute->flow,
>   execute->actions, execute->actions_len);
> dp_netdev_pmd_flush_output_packets(pmd, true);
> 
> Unfortunately, I now get some errors in the "make check", including:
> 
> 1012: PMD - monitor threads   FAILED (pmd.at:657 
> )
> 1018: ofproto-dpif - active-backup bonding (with primary) FAILED 
> (ofproto-dpif.at:70 )
> 1020: ofproto-dpif - active-backup bonding (without primary) FAILED 
> (ofproto-dpif.at:288 )
> 1184: ofproto-dpif megaflow - normal, balance-tcp bonding FAILED 
> (ofproto-dpif.at:8664 )
> 
> My earlier analysis of the code showed that a call tree starting from 
> handle_upcalls can also result in
> dpif_netdev_execute getting called - I wonder if that's what's happening 
> here? I'll keep analysing these
> new failures, but any pointers would be appreciated.
> 
> Tony
> 
> On Tue, Jun 15, 2021 at 12:28 PM Tony van der Peet  > wrote:
> 
> Yes, I can create that patch.
> 
> Tony
> 
> On Sat, Jun 12, 2021 at 5:24 AM Ilya Maximets  > wrote:
> 
> On 6/9/21 3:12 PM, Aaron Conole wrote:
> > Ilya Maximets mailto:i.maxim...@ovn.org>> 
> writes:
> >
> >> On 6/7/21 3:59 PM, Ilya Maximets wrote:
> >>> On 6/7/21 3:09 PM, Aaron Conole wrote:
>  Ilya Maximets mailto:i.maxim...@ovn.org>> 
> writes:
> 
> >> Here is a patch with both a test and a fix.
> 
>  Thanks so much!  It's nice to get fixes, but I think it's really 
> great
>  when test cases come along with them.
> 
> > Hi.  Thanks for working n this!
> >
> > CC: ovs-dev
> >
> >> Not submitting as a formal
> >> patch because I would like some feedback on whether 1) 
> maintainers feel
> >> this is worth fixing and
> >
> > I can reproduce the crash with your test.  Basically, actions 
> in userspace
> > datapath may drop packets if something goes wrong.  'meter' 
> action just
> > seems to be the most explicit variant.  So, I think, this is 
> definitely
> > worth fixing as some other condition might trigger this crash 
> on packet-out
> > as well.
> >
> > ==2568112==ERROR: AddressSanitizer: heap-use-after-free
> > on address 0x6160699c at pc 0x00573860 bp 
> 0x7ffebc6cc880 sp 0x7ffebc6cc878
> > READ of size 1 at 0x6160699c thread T0
> >     #0 0x57385f in dp_packet_delete lib/dp-packet.h:242:16
> >     #1 0x57372c in ofproto_packet_out_uninit 
> ofproto/ofproto.c:3562:5
> >     #2 0x585e77 in handle_packet_out ofproto/ofproto.c:3722:5
> >     #3 0x583801 in handle_single_part_openflow 
> ofproto/ofproto.c:8499:16
> >     #4 0x570c9c in handle_openflow ofproto/ofproto.c:8686:21
> >     #5 0x611781 in ofconn_run ofproto/connmgr.c:1329:13
> >     #6 0x6112ed in connmgr_run ofproto/connmgr.c:356:9
> >     #7 0x56fdf4 in ofproto_run ofproto/ofproto.c:1891:5
> >     #8 0x545ec0 in bridge_run__ vswitchd/bridge.c:3251:9
> >     #9 0x5456a5 in bridge_run vswitchd/bridge.c:3310:5
> >     #10 0x55f5b1 in main vswitchd/ovs-vswitchd.c:127:9
> >     #11 0x7f85bfe09081 in __libc_start_main 
> (/lib64/libc.so.6+0x27081)
> >     #12 0x46d00d in _start (vswitchd/ovs-vswitchd+0x46d00d)
> >
> >> 2) whether this is the way to fix it.
> >
> > See inline.
> >
> >>
> >> I have tried to make the most minimal

Re: [ovs-discuss] Inactivity Probe configuration not taking effect in OVS 2.14.0

2021-06-15 Thread Saurabh Deokate 
Hi Ben,

Here is the output for ovs-vsctl list controller 

[root@172-31-64-26-aws-eu-central-1c ~]# ovs-vsctl list controller
_uuid : eb56176a-ad32-4eb0-9cd8-7ab3bd448a68
connection_mode : out-of-band
controller_burst_limit: []
controller_queue_size: []
controller_rate_limit: []
enable_async_messages: []
external_ids : {}
inactivity_probe : 0
is_connected : true
local_gateway : []
local_ip : []
local_netmask : []
max_backoff : []
other_config : {}
role : other
status : {last_error="Connection refused", sec_since_connect="42606", 
sec_since_disconnect="42614", state=ACTIVE}
target : "tcp:127.0.0.1:6653"
type : []

Let me know if you need any other details.

~Saurabh.

On 11/06/21, 4:03 AM, "Ben Pfaff"  wrote:

On Mon, Jun 07, 2021 at 02:51:58PM +, Saurabh Deokate wrote:
> Hi Team,
> 
> We are seeing an issue in OVS 2.14.0 after moving from 2.8.0. We first 
set the controller on the bridge and then set inactivity probe for our 
controller to 0 to disable new connection attempts by ovs. After this we start 
our controller to serve request. But in the new version of OVS somehow we still 
see inactivity probe kicking in after every 5s and trying to reconnect. This 
issue is triggered when we are in the middle of handling a packet in our 
controller (i.e. OFController) which is blocked for almost 40s.
> 
> 
> Kernel version: CentOS Linux release 7.9.2009
> Output of ovs-vsctl list controller command shows inactivity_probe: 0
> 
> Below is the snippet from ovs-vswitchd.log
> 
> 021-05-11T22:32:55.378Z|00608|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
connected
> 
2021-05-11T22:33:05.382Z|00609|connmgr|INFO|br0.uvms<->tcp:127.0.0.1:6653: 44 
flow_mods 10 s ago (44 adds)
> 2021-05-11T22:33:05.386Z|00610|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: 
no response to inactivity probe after 5 seconds, disconnecting
> 2021-05-11T22:33:06.406Z|00611|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
connecting...
> 2021-05-11T22:33:06.438Z|00612|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
connected
> 2021-05-11T22:33:16.438Z|00613|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: 
no response to inactivity probe after 5 seconds, disconnecting
> 2021-05-11T22:33:17.921Z|00614|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
connecting...
> 2021-05-11T22:33:18.108Z|00615|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
connected
> 2021-05-11T22:33:28.110Z|00616|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: 
no response to inactivity probe after 5 seconds, disconnecting
> 2021-05-11T22:33:29.433Z|00617|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
connecting...
> 2021-05-11T22:33:29.933Z|00618|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
connected
> 
> 
> Can you please help us find out what could be wrong with this 
configuration and what is the expected behaviour from ovs switch when the 
receiver on the controller is blocked for long.

Hmm, I can't reproduce this with current OVS.  I do see a problem with
the fail-open implementation; I'll see a patch for that.

Can you show the output of "ovs-vsctl list controller"?

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss