Re: [ovs-discuss] [OVN] ACLs not translated to SB when added to multiple port groups

[Numan Siddique via discuss]

On Wed, Oct 30, 2024 at 2:31 AM Qin, Qiaofeng via discuss
 wrote:
>
> Hi Numan,
>
> Thank you for the reply. Yes, The given command (ovn-appctl -t ovn-northd 
> inc-engine/recompute) can fix the issue without restarting. Besides, we also 
> found that creating a logical switch (ovn-nbctl ls-add test3) can make the 
> missing ACL appear in SB.

One work around before this issue is fixed is to create a separate
ACLs for each port group rather than sharing across pgs.

Thanks
Numan

>
>
> Thanks,
> Qiaofeng
> ____
> From: Numan Siddique 
> Sent: Tuesday, October 29, 2024 7:41 PM
> To: Qin, Qiaofeng 
> Cc: b...@openvswitch.org 
> Subject: Re: [ovs-discuss] [OVN] ACLs not translated to SB when added to 
> multiple port groups
>
> On Tue, Oct 29, 2024 at 8:47 PM Qin, Qiaofeng via discuss
>  wrote:
> >
> > Hi,
> >
> > Recently, we encountered an issue when assigning some ACLs to two port 
> > groups. When configuring the first ACL, everything looks correct. However, 
> > after creating the second ACL and assigning it to the second port group, 
> > the ACL does not appear in the Logical_Flow table, until we continue to 
> > perform some other operations in the northbound or restart ovn-northd. I 
> > wonder if this is a bug or a known limitation.
> >
> > We installed ovn-central 24.09.0 through apt in a Debian Sid host. The 
> > following logs are the steps to reproduce the issue:
> >
> >
> > # Setup: 2 switches, 2 ports and 2 port groups
> > root@38469380e572:/# ovn-nbctl ls-add test1
> > root@38469380e572:/# ovn-nbctl ls-add test2
> > root@38469380e572:/# ovn-nbctl lsp-add test1 p1
> > root@38469380e572:/# ovn-nbctl lsp-add test2 p2
> > root@38469380e572:/# ovn-nbctl pg-add g1
> > root@38469380e572:/# ovn-nbctl pg-add g2 p1 p2
> >
> > # Assign acl1 first to g1, then to g2
> > root@334a6440dc45:/# ovn-nbctl --name=rule1 acl-add g1 from-lport 100 
> > "foo1" drop
> > root@334a6440dc45:/# ovn-nbctl list acl rule1 | grep uuid
> > _uuid   : fa7caa68-d4fa-4e69-8274-c5e5b57490aa
> > root@334a6440dc45:/# ovn-nbctl add port_group g2 acls 
> > fa7caa68-d4fa-4e69-8274-c5e5b57490aa
> >
> > # Northbound results: Correct
> > root@334a6440dc45:/# ovn-nbctl acl-list g1
> > from-lport   100 (foo1) drop log(name=rule1)
> > root@334a6440dc45:/# ovn-nbctl acl-list g2
> > from-lport   100 (foo1) drop log(name=rule1)
> >
> > # Southbound results: Correct
> > root@334a6440dc45:/# ovn-sbctl dump-flows | grep foo
> >   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo1)), 
> > action=(log(name="rule1", severity=info, verdict=drop); reg8[17] = 1; next;)
> >   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo1)), 
> > action=(log(name="rule1", severity=info, verdict=drop); reg8[17] = 1; next;)
> >
> > # Assign acl2 first to g1, then to g2
> > root@334a6440dc45:/# ovn-nbctl --name=rule2 acl-add g1 from-lport 100 
> > "foo2" drop
> > root@334a6440dc45:/# ovn-nbctl list acl rule2 | grep uuid
> > _uuid   : 6b6080e5-1ecf-4d1d-bb86-8eb487c622c0
> > root@334a6440dc45:/# ovn-nbctl add port_group g2 acls 
> > 6b6080e5-1ecf-4d1d-bb86-8eb487c622c0
> >
> > # Northbound results: Correct
> > root@334a6440dc45:/# ovn-nbctl acl-list g1
> > from-lport   100 (foo1) drop log(name=rule1)
> > from-lport   100 (foo2) drop log(name=rule2)
> > root@334a6440dc45:/# ovn-nbctl acl-list g2
> > from-lport   100 (foo1) drop log(name=rule1)
> > from-lport   100 (foo2) drop log(name=rule2)
> >
> > # Southbound results: Incorrect - Second ACL does not show
> > root@334a6440dc45:/# ovn-sbctl dump-flows | grep foo
> >   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo1)), 
> > action=(log(name="rule1", severity=info, verdict=drop); reg8[17] = 1; next;)
> >   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo1)), 
> > action=(log(name="rule1", severity=info, verdict=drop); reg8[17] = 1; next;)
> >
> > # Remove acl1 from g2
> > root@334a6440dc45:/# ovn-nbctl acl-del g2 from-lport 100 "foo1"
> >
> > # Northbound results: Correct
> > root@334a6440dc45:/# ovn-nbctl acl-list g1
> > from-lport   100 (foo1) drop log(name=rule1)
> > from-lport   100 (foo2) drop log(name=rule2)
> > root@334a6440dc45:/# ovn-nbctl acl-list g2
> > from-lport   100 (foo2) drop log(name=rule2)
> >
> > # Southbound results: Incorrect - first ACL not removed
> > root@334a6440dc45:/# ovn-sbctl dump-flows | grep foo
> >

Re: [ovs-discuss] [OVN] ACLs not translated to SB when added to multiple port groups

[Numan Siddique via discuss]

On Tue, Oct 29, 2024 at 8:47 PM Qin, Qiaofeng via discuss
 wrote:
>
> Hi,
>
> Recently, we encountered an issue when assigning some ACLs to two port 
> groups. When configuring the first ACL, everything looks correct. However, 
> after creating the second ACL and assigning it to the second port group, the 
> ACL does not appear in the Logical_Flow table, until we continue to perform 
> some other operations in the northbound or restart ovn-northd. I wonder if 
> this is a bug or a known limitation.
>
> We installed ovn-central 24.09.0 through apt in a Debian Sid host. The 
> following logs are the steps to reproduce the issue:
>
>
> # Setup: 2 switches, 2 ports and 2 port groups
> root@38469380e572:/# ovn-nbctl ls-add test1
> root@38469380e572:/# ovn-nbctl ls-add test2
> root@38469380e572:/# ovn-nbctl lsp-add test1 p1
> root@38469380e572:/# ovn-nbctl lsp-add test2 p2
> root@38469380e572:/# ovn-nbctl pg-add g1
> root@38469380e572:/# ovn-nbctl pg-add g2 p1 p2
>
> # Assign acl1 first to g1, then to g2
> root@334a6440dc45:/# ovn-nbctl --name=rule1 acl-add g1 from-lport 100 "foo1" 
> drop
> root@334a6440dc45:/# ovn-nbctl list acl rule1 | grep uuid
> _uuid   : fa7caa68-d4fa-4e69-8274-c5e5b57490aa
> root@334a6440dc45:/# ovn-nbctl add port_group g2 acls 
> fa7caa68-d4fa-4e69-8274-c5e5b57490aa
>
> # Northbound results: Correct
> root@334a6440dc45:/# ovn-nbctl acl-list g1
> from-lport   100 (foo1) drop log(name=rule1)
> root@334a6440dc45:/# ovn-nbctl acl-list g2
> from-lport   100 (foo1) drop log(name=rule1)
>
> # Southbound results: Correct
> root@334a6440dc45:/# ovn-sbctl dump-flows | grep foo
>   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo1)), 
> action=(log(name="rule1", severity=info, verdict=drop); reg8[17] = 1; next;)
>   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo1)), 
> action=(log(name="rule1", severity=info, verdict=drop); reg8[17] = 1; next;)
>
> # Assign acl2 first to g1, then to g2
> root@334a6440dc45:/# ovn-nbctl --name=rule2 acl-add g1 from-lport 100 "foo2" 
> drop
> root@334a6440dc45:/# ovn-nbctl list acl rule2 | grep uuid
> _uuid   : 6b6080e5-1ecf-4d1d-bb86-8eb487c622c0
> root@334a6440dc45:/# ovn-nbctl add port_group g2 acls 
> 6b6080e5-1ecf-4d1d-bb86-8eb487c622c0
>
> # Northbound results: Correct
> root@334a6440dc45:/# ovn-nbctl acl-list g1
> from-lport   100 (foo1) drop log(name=rule1)
> from-lport   100 (foo2) drop log(name=rule2)
> root@334a6440dc45:/# ovn-nbctl acl-list g2
> from-lport   100 (foo1) drop log(name=rule1)
> from-lport   100 (foo2) drop log(name=rule2)
>
> # Southbound results: Incorrect - Second ACL does not show
> root@334a6440dc45:/# ovn-sbctl dump-flows | grep foo
>   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo1)), 
> action=(log(name="rule1", severity=info, verdict=drop); reg8[17] = 1; next;)
>   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo1)), 
> action=(log(name="rule1", severity=info, verdict=drop); reg8[17] = 1; next;)
>
> # Remove acl1 from g2
> root@334a6440dc45:/# ovn-nbctl acl-del g2 from-lport 100 "foo1"
>
> # Northbound results: Correct
> root@334a6440dc45:/# ovn-nbctl acl-list g1
> from-lport   100 (foo1) drop log(name=rule1)
> from-lport   100 (foo2) drop log(name=rule2)
> root@334a6440dc45:/# ovn-nbctl acl-list g2
> from-lport   100 (foo2) drop log(name=rule2)
>
> # Southbound results: Incorrect - first ACL not removed
> root@334a6440dc45:/# ovn-sbctl dump-flows | grep foo
>   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo1)), 
> action=(log(name="rule1", severity=info, verdict=drop); reg8[17] = 1; next;)
>   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo1)), 
> action=(log(name="rule1", severity=info, verdict=drop); reg8[17] = 1; next;)
>
> # Restart OVN can fix the inconsistency: acl1 removed, acl2 appears
> root@334a6440dc45:/# ovn-ctl restart_northd
> root@334a6440dc45:/# ovn-sbctl dump-flows | grep foo
>   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo2)), 
> action=(log(name="rule2", severity=info, verdict=drop); reg8[17] = 1; next;)
>   table=8 (ls_in_acl_eval ), priority=1100 , match=((foo2)), 
> action=(log(name="rule2", severity=info, verdict=drop); reg8[17] = 1; next;)
>
>
> When we assigned each ACL to only one port group, we did not observe the same 
> issue. When we assigned ACLs to (either one or more) logical switches instead 
> of port groups, this issue also did not happen.

Thanks for reporting the issue.  Looks like a bug to me in ovn-northd.

Can you please run the below command instead of restarting and see if
it fixes the issue ?  If so, it seems like an incremental processing
bug in ovn-northd.

ovn-appctl -t ovn-northd inc-engine/recompute

Thanks
Numan


>
> Thanks,
> Qiaofeng
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswi

Re: [ovs-discuss] [OVN] DBs RAFT Cluster Issue

[Numan Siddique via discuss]

On Wed, Oct 16, 2024 at 9:12 AM Ammad Syed via discuss
 wrote:
>
> Hi,
>
> I am testing ovn 3 nodes clustering with ssl setup on ovn 24.04.2.
>
> These are ovn options that I have set on node 1.
>
> OVN_CTL_OPTS=" \
>   --db-nb-create-insecure-remote=no \
>   --db-sb-create-insecure-remote=no \
>   --db-nb-addr=172.16.60.40 \
>   --db-sb-addr=172.16.60.40 \
>   --db-nb-cluster-local-addr=172.16.60.40 \
>   --db-nb-cluster-local-proto=ssl \
>   --db-sb-cluster-local-addr=172.16.60.40 \
>   --db-sb-cluster-local-proto=ssl \
>   --ovn-northd-nb-db=ssl:172.16.60.40:6641 \
>   --ovn-northd-sb-db=ssl:172.16.60.40:6642 \
>   
> --ovn-northd-nb-db=ssl:172.16.60.40:6641,ssl:172.16.60.41:6641,ssl:172.16.60.42:6641
>  \
>   
> --ovn-northd-sb-db=ssl:172.16.60.40:6642,ssl:172.16.60.41:6642,ssl:172.16.60.42:6642
>  \
>   --ovn-nb-db-ssl-key=/etc/ovn/ovn-cert/ovnnb-privkey.pem \
>   --ovn-nb-db-ssl-cert=/etc/ovn/ovn-cert/ovnnb-cert.pem \
>   --ovn-nb-db-ssl-ca-cert=/etc/ovn/ovn-cert/cacert.pem \
>   --ovn-sb-db-ssl-key=/etc/ovn/ovn-cert/ovnsb-privkey.pem \
>   --ovn-sb-db-ssl-cert=/etc/ovn/ovn-cert/ovnsb-cert.pem \
>   --ovn-sb-db-ssl-ca-cert=/etc/ovn/ovn-cert/cacert.pem \
>   --ovn-northd-ssl-key=/etc/ovn/ovn-cert/ovnnorthd-privkey.pem \
>   --ovn-northd-ssl-cert=/etc/ovn/ovn-cert/ovnnorthd-cert.pem \
>   --ovn-northd-ssl-ca-cert=/etc/ovn/ovn-cert/cacert.pem \
> "
>
> On the second and third node I have used below options.
>
> OVN_CTL_OPTS=" \
>   --db-nb-create-insecure-remote=no \
>   --db-sb-create-insecure-remote=no \
>   --db-nb-addr=172.16.60.41 \
>   --db-sb-addr=172.16.60.41 \
>   --db-nb-cluster-local-addr=172.16.60.41 \
>   --db-nb-cluster-local-proto=ssl \
>   --db-sb-cluster-local-addr=172.16.60.41 \
>   --db-sb-cluster-local-proto=ssl \
>   --db-nb-cluster-remote-addr=172.16.60.40 \
>   --db-nb-cluster-remote-proto=ssl \
>   --db-sb-cluster-remote-addr=172.16.60.40 \
>   --db-sb-cluster-remote-proto=ssl \
>   
> --ovn-northd-nb-db=ssl:172.16.60.40:6641,ssl:172.16.60.41:6641,ssl:172.16.60.42:6641
>  \
>   
> --ovn-northd-sb-db=ssl:172.16.60.40:6642,ssl:172.16.60.41:6642,ssl:172.16.60.42:6642
>  \
>   --ovn-nb-db-ssl-key=/etc/ovn/ovn-cert/ovnnb-privkey.pem \
>   --ovn-nb-db-ssl-cert=/etc/ovn/ovn-cert/ovnnb-cert.pem \
>   --ovn-nb-db-ssl-ca-cert=/etc/ovn/ovn-cert/cacert.pem \
>   --ovn-sb-db-ssl-key=/etc/ovn/ovn-cert/ovnsb-privkey.pem \
>   --ovn-sb-db-ssl-cert=/etc/ovn/ovn-cert/ovnsb-cert.pem \
>   --ovn-sb-db-ssl-ca-cert=/etc/ovn/ovn-cert/cacert.pem \
>   --ovn-northd-ssl-key=/etc/ovn/ovn-cert/ovnnorthd-privkey.pem \
>   --ovn-northd-ssl-cert=/etc/ovn/ovn-cert/ovnnorthd-cert.pem \
>   --ovn-northd-ssl-ca-cert=/etc/ovn/ovn-cert/cacert.pem \
>   --ovn-northd-nb-db=ssl:172.16.60.41:6641 \
>   --ovn-northd-sb-db=ssl:172.16.60.41:6642 \
> "
>
> Here is the cluster status.
>
> # ovs-appctl -t /var/run/ovn/ovnnb_db.ctl cluster/status OVN_Northbound
> db6a
> Name: OVN_Northbound
> Cluster ID: 5502 (5502d208-61dc-4eee-bd15-dc0dc52bf379)
> Server ID: db6a (db6a618a-bf77-4f46-b08d-ebf15d538ee5)
> Address: ssl:172.16.60.42:6643
> Status: cluster member
> Role: leader
> Term: 12
> Leader: self
> Vote: self
>
> Last Election started 3584828 ms ago, reason: leadership_transfer
> Last Election won: 3584825 ms ago
> Election timer: 1000
> Log: [2, 17]
> Entries not yet committed: 0
> Entries not yet applied: 0
> Connections: ->f588 ->1902 <-f588 <-1902
> Disconnections: 3
> Servers:
> f588 (f588 at ssl:172.16.60.40:6643) next_index=17 match_index=16 last 
> msg 75 ms ago
> db6a (db6a at ssl:172.16.60.42:6643) (self) next_index=15 match_index=16
> 1902 (1902 at ssl:172.16.60.41:6643) next_index=17 match_index=16 last 
> msg 75 ms ago
>
> The issue is I am seeing below logs in follower instances continuously.
>
> 2024-10-16T13:05:51.106Z|03078|ovsdb_cs|INFO|ssl:172.16.60.41:6641: clustered 
> database server is not cluster leader; trying another server
> 2024-10-16T13:05:51.106Z|03079|ovn_northd|INFO|ovn-northd lock acquired. This 
> ovn-northd instance is now active.
> 2024-10-16T13:05:51.106Z|03080|ovsdb_cs|INFO|ssl:172.16.60.41:6642: clustered 
> database server is not cluster leader; trying another server
> 2024-10-16T13:05:51.107Z|03081|ovn_northd|INFO|ovn-northd lock lost. This 
> ovn-northd instance is now on standby.
> 2024-10-16T13:05:59.116Z|03082|reconnect|INFO|ssl:172.16.60.41:6641: connected
> 2024-10-16T13:05:59.118Z|03083|reconnect|INFO|ssl:172.16.60.41:6642: connected
> 2024-10-16T13:05:59.118Z|03084|ovsdb_cs|INFO|ssl:172.16.60.41:6641: clustered 
> database server is not cluster leader; trying another server
> 2024-10-16T13:05:59.119Z|03085|ovn_northd|INFO|ovn-northd lock acquired. This 
> ovn-northd instance is now active.
> 2024-10-16T13:05:59.119Z|03086|ovsdb_cs|INFO|ssl:172.16.60.41:6642: clustered 
> database server is not cluster leader; trying another server
> 2024-10-16T13:05:59.119Z|03087|ovn_northd|INFO|ovn-northd lock lost. This 
> ovn-northd instance is now on standby.
> 2024-10-16T13:

Re: [ovs-discuss] (no subject)

[Numan Siddique via discuss]

On Tue, Oct 8, 2024 at 12:37 AM Gavin McKee via discuss
 wrote:
>
> Awesome . Thanks for taking a look at this .

Hi Gavin,

I've posted a patch to address this -
https://patchwork.ozlabs.org/project/ovn/patch/2024101239.1057750-1-num...@ovn.org/

It would be great if you can test it out and see if it addresses your
issues.  The same can be found here too -
https://github.com/numansiddique/ovn/tree/sbdns_ip/v1

Thanks
Numan

>
> Gav
>
> On Mon, Oct 7, 2024 at 18:46 Numan Siddique  wrote:
>>
>> On Mon, Oct 7, 2024 at 1:33 PM Gavin McKee via discuss
>>  wrote:
>> >
>> > Hi Numan,
>> >
>> > Yes, DNS entries can be added / moved / updated frequently in our
>> > setup . Our usebase can create or delete VMs in bulk using Terraform
>> > so it's likely that we should handle a scenario where these actions
>> > don't block DNS lookups.
>> >
>> > I'm in deeper water than usual here so would appreciate it if you
>> > could make a proposal for the dns_cache_mutex .  I'm fully open to any
>> > approach that will ensure that we keep processing DNS requests
>> > (especially the external) as blocking these is a big problem.
>>
>> I've some ideas.  I'll see if I can spin up a patch.
>>
>> Thanks
>> Numan
>>
>> >
>> > Gav
>> >
>> > On Mon, 7 Oct 2024 at 10:07, Numan Siddique  wrote:
>> > >
>> > > On Mon, Oct 7, 2024 at 12:13 PM Gavin McKee via discuss
>> > >  wrote:
>> > > >
>> > > > Numan,
>> > > >
>> > > > Hopefully I don't embarrass myself too much here, but here goes :) .
>> > > > If we implemented a separate thread for performing DNS lookups would
>> > > > that work ?
>> > >
>> > > I see a couple of  problems here.
>> > >
>> > > 1.  The new thread will be sharing the "swconn" connection with
>> > > the pinctrl thread. Not sure how much of any issue this may cause.
>> > > Looks like "rconn_send" has a mutex.
>> > >
>> > > 2.  There is a possibility that when the new thread iterates over the
>> > > dns_cache shash, the main ovn-controller
>> > > thread can modify this from pinctrl_run().
>> > >
>> > >  Before going this way,  is it possible to explore adding another
>> > > mutex say - "dns_cache_mutex" (or any other appropriate name).
>> > >
>> > > pinctrl thread before calling pinctrl_handle_dns_lookup() will lock
>> > > this mutex instead of the
>> > > main "pinctrl_mutex" and sync_dns_cache() will lock this mutex when it
>> > > is adding or deleting the dns_cache.
>> > >
>> > > What do you think ?  This way dns requests will not be blocked due to
>> > > ovn-controller waking up and calling pinctrl_run().
>> > > It will be blocked though when SB dns entries are updated.   Or is
>> > > that the case in your setup ? Do OVN dns records
>> > > get updated  very frequently ?
>> > >
>> > > Thanks
>> > > Numan
>> > >
>> > > >
>> > > > diff --git a/controller/pinctrl.c b/controller/pinctrl.c
>> > > > index c86b4f940..aaa316542 100644
>> > > > --- a/controller/pinctrl.c
>> > > > +++ b/controller/pinctrl.c
>> > > > @@ -189,6 +189,27 @@ static struct pinctrl pinctrl;
>> > > >
>> > > >  static void init_buffered_packets_ctx(void);
>> > > >  static void destroy_buffered_packets_ctx(void);
>> > > > +
>> > > > +/* DNS thread */
>> > > > +static struct latch dns_thread_exit;
>> > > > +static pthread_t dns_thread;
>> > > > +
>> > > > +/* DNS query queue */
>> > > > +struct dns_query {
>> > > > +struct dp_packet packet;
>> > > > +struct ofputil_packet_in pin;
>> > > > +struct ofpbuf userdata;
>> > > > +struct ofpbuf *continuation;
>> > > > +struct ovs_list node;
>> > > > +};
>> > > > +
>> > > > +static struct ovs_list dns_query_queue =
>> > > > OVS_LIST_INITIALIZER(&dns_query_queue);
>> > > > +static struct ovs_mutex dns_queue_mutex = OVS_MUTEX_INITIALIZER;
>> > > > +static struct seq *dns_seq;
>> > > > +
>> > > > +static void dns

Re: [ovs-discuss] Network visualizer

[Numan Siddique via discuss]

On Mon, Oct 7, 2024 at 5:39 AM Adrián Moreno via discuss
 wrote:
>
> On Thu, Oct 03, 2024 at 07:41:11PM GMT, engineer2024 via discuss wrote:
> > Are there any network visualization tools available which can scan the
> > entire OVN network on a given host and create graphic representation with
> > ovs components and their connections along with the ports inside them ?
> >
>
> I don't know of any at the OVN level. At the host level you can try
> plotnetcfg:
>
> https://github.com/jbenc/plotnetcfg/

You can also check this tool - https://skydive.network/

Thanks
Numan

>
> Thanks
> --
> Adrián
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] (no subject)

[Numan Siddique via discuss]

On Mon, Oct 7, 2024 at 1:33 PM Gavin McKee via discuss
 wrote:
>
> Hi Numan,
>
> Yes, DNS entries can be added / moved / updated frequently in our
> setup . Our usebase can create or delete VMs in bulk using Terraform
> so it's likely that we should handle a scenario where these actions
> don't block DNS lookups.
>
> I'm in deeper water than usual here so would appreciate it if you
> could make a proposal for the dns_cache_mutex .  I'm fully open to any
> approach that will ensure that we keep processing DNS requests
> (especially the external) as blocking these is a big problem.

I've some ideas.  I'll see if I can spin up a patch.

Thanks
Numan

>
> Gav
>
> On Mon, 7 Oct 2024 at 10:07, Numan Siddique  wrote:
> >
> > On Mon, Oct 7, 2024 at 12:13 PM Gavin McKee via discuss
> >  wrote:
> > >
> > > Numan,
> > >
> > > Hopefully I don't embarrass myself too much here, but here goes :) .
> > > If we implemented a separate thread for performing DNS lookups would
> > > that work ?
> >
> > I see a couple of  problems here.
> >
> > 1.  The new thread will be sharing the "swconn" connection with
> > the pinctrl thread. Not sure how much of any issue this may cause.
> > Looks like "rconn_send" has a mutex.
> >
> > 2.  There is a possibility that when the new thread iterates over the
> > dns_cache shash, the main ovn-controller
> > thread can modify this from pinctrl_run().
> >
> >  Before going this way,  is it possible to explore adding another
> > mutex say - "dns_cache_mutex" (or any other appropriate name).
> >
> > pinctrl thread before calling pinctrl_handle_dns_lookup() will lock
> > this mutex instead of the
> > main "pinctrl_mutex" and sync_dns_cache() will lock this mutex when it
> > is adding or deleting the dns_cache.
> >
> > What do you think ?  This way dns requests will not be blocked due to
> > ovn-controller waking up and calling pinctrl_run().
> > It will be blocked though when SB dns entries are updated.   Or is
> > that the case in your setup ? Do OVN dns records
> > get updated  very frequently ?
> >
> > Thanks
> > Numan
> >
> > >
> > > diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> > > index c86b4f940..aaa316542 100644
> > > --- a/controller/pinctrl.c
> > > +++ b/controller/pinctrl.c
> > > @@ -189,6 +189,27 @@ static struct pinctrl pinctrl;
> > >
> > >  static void init_buffered_packets_ctx(void);
> > >  static void destroy_buffered_packets_ctx(void);
> > > +
> > > +/* DNS thread */
> > > +static struct latch dns_thread_exit;
> > > +static pthread_t dns_thread;
> > > +
> > > +/* DNS query queue */
> > > +struct dns_query {
> > > +struct dp_packet packet;
> > > +struct ofputil_packet_in pin;
> > > +struct ofpbuf userdata;
> > > +struct ofpbuf *continuation;
> > > +struct ovs_list node;
> > > +};
> > > +
> > > +static struct ovs_list dns_query_queue =
> > > OVS_LIST_INITIALIZER(&dns_query_queue);
> > > +static struct ovs_mutex dns_queue_mutex = OVS_MUTEX_INITIALIZER;
> > > +static struct seq *dns_seq;
> > > +
> > > +static void dns_queue_push(struct dns_query *query);
> > > +static struct dns_query *dns_queue_pop(void);
> > > +static void *dns_lookup_thread(void *arg OVS_UNUSED);
> > >  static void
> > >  run_buffered_binding(const struct sbrec_mac_binding_table 
> > > *mac_binding_table,
> > >   struct ovsdb_idl_index *sbrec_port_binding_by_key,
> > > @@ -572,6 +593,10 @@ pinctrl_init(void)
> > >  latch_init(&pinctrl.pinctrl_thread_exit);
> > >  pinctrl.pinctrl_thread = ovs_thread_create("ovn_pinctrl", 
> > > pinctrl_handler,
> > >  &pinctrl);
> > > +latch_init(&dns_thread_exit);
> > > +dns_seq = seq_create();
> > > +pinctrl.dns_thread = ovs_thread_create("dns_lookup",
> > > dns_lookup_thread, NULL);
> > > +
> > >  }
> > >
> > >  static ovs_be32
> > > @@ -3435,6 +3460,51 @@ dns_build_ptr_answer(
> > >  #define DNS_RCODE_SERVER_REFUSE 0x5
> > >  #define DNS_QUERY_TYPE_CLASS_LEN (2 * sizeof(ovs_be16))
> > >
> > > +static void *
> > > +dns_lookup_thread(void *arg OVS_UNUSED)
> > > +{
> > >

Re: [ovs-discuss] (no subject)

[Numan Siddique via discuss]

>  pinctrl_handle_dns_lookup(
> @@ -3804,11 +3874,16 @@ process_packet_in(struct rconn *swconn, const
> struct ofp_header *msg)
>  break;
>
>  case ACTION_OPCODE_DNS_LOOKUP:
> -ovs_mutex_lock(&pinctrl_mutex);
> -pinctrl_handle_dns_lookup(swconn, &packet, &pin, &userdata,
> -  &continuation);
> -ovs_mutex_unlock(&pinctrl_mutex);
> -break;
> +{
> +struct dns_query *query = xmalloc(sizeof *query);
> +dp_packet_clone(&query->packet, &packet);
> +query->pin = pin;
> +ofpbuf_clone(&query->userdata, &userdata);
> +query->continuation = continuation ? ofpbuf_clone(continuation) : 
> NULL;
> +dns_queue_push(query);
> +poll_immediate_wake();
> +}
> +    break;
>
>  case ACTION_OPCODE_LOG:
>  handle_acl_log(&headers, &userdata,
>
> On Fri, 4 Oct 2024 at 15:59, Gavin McKee  wrote:
> >
> > Hi Numan,
> >
> > Yes , the DNS packets are sent by VMs . We have DNS records for these VMs 
> > so the controller is catching all DNS requests and failing to respond in a 
> > timely manner.
> >
> >  I think this relates to the fact that there is no incremental handler for 
> > SB DNS.
> >
> > In short the blocking thread causes us all sorts of problems .
> >
> > Hope that makes sense
> >
> > Gav
> >
> > On Fri, Oct 4, 2024 at 15:34 Numan Siddique  wrote:
> >>
> >> On Fri, Oct 4, 2024 at 5:50 PM Gavin McKee via discuss
> >>  wrote:
> >> >
> >> > Hi,
> >> >
> >> > We currently experience DNS related timeouts when the ovn controller
> >> > is under high load.
> >> >
> >> > Will this commit ensure that DNS packets needing to be forwarded to an
> >> > external resolver will be processed in a timely manner and not lead to
> >> > timeouts?
> >> > https://github.com/ovn-org/ovn/commit/762ae66cd70efa149d91d35305fcef0040e9addd
> >> >
> >>
> >> This particular patch is useful when the ovn-controller calls
> >> dns_resolve() of ovs/lib/dns_resolve.c [1]
> >> to resolve a dns entry.
> >>
> >> In your case, what are these DNS packets?  Are these sent by VMs and
> >> ovn-controller pinctrl thread handles
> >> these requests and its blocking due to pinctrl_mutex ?
> >>
> >> If so,  I think we need to find a solution for this problem, but the
> >> above commit will definitely not help you.
> >> Maybe we can maintain a separate mutex to protect the dns_cache [2] so
> >> that even if ovn-controller main thread
> >> is busy (and not updating the internal dns cache), the DNS packets
> >> from the VMs can be handled without any delay
> >> in the pinctrl thread.
> >>
> >> [1] - https://github.com/openvswitch/ovs/blob/main/lib/dns-resolve.c#L148
> >> [2] - https://github.com/ovn-org/ovn/blob/main/controller/pinctrl.c#L3288
> >>
> >>
> >> Thanks
> >> Numan
> >>
> >> > We currently run OVN 23.09.04.
> >> >
> >> > Thanks
> >> >
> >> > Gav
> >> > ___
> >> > discuss mailing list
> >> > disc...@openvswitch.org
> >> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >> >
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] (no subject)

[Numan Siddique via discuss]

On Fri, Oct 4, 2024 at 5:50 PM Gavin McKee via discuss
 wrote:
>
> Hi,
>
> We currently experience DNS related timeouts when the ovn controller
> is under high load.
>
> Will this commit ensure that DNS packets needing to be forwarded to an
> external resolver will be processed in a timely manner and not lead to
> timeouts?
> https://github.com/ovn-org/ovn/commit/762ae66cd70efa149d91d35305fcef0040e9addd
>

This particular patch is useful when the ovn-controller calls
dns_resolve() of ovs/lib/dns_resolve.c [1]
to resolve a dns entry.

In your case, what are these DNS packets?  Are these sent by VMs and
ovn-controller pinctrl thread handles
these requests and its blocking due to pinctrl_mutex ?

If so,  I think we need to find a solution for this problem, but the
above commit will definitely not help you.
Maybe we can maintain a separate mutex to protect the dns_cache [2] so
that even if ovn-controller main thread
is busy (and not updating the internal dns cache), the DNS packets
from the VMs can be handled without any delay
in the pinctrl thread.

[1] - https://github.com/openvswitch/ovs/blob/main/lib/dns-resolve.c#L148
[2] - https://github.com/ovn-org/ovn/blob/main/controller/pinctrl.c#L3288


Thanks
Numan

> We currently run OVN 23.09.04.
>
> Thanks
>
> Gav
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Request for Guidance on Patch Submission and 'Signed-off-by' Procedure

[Numan Siddique via discuss]

On Tue, Sep 10, 2024 at 8:26 AM Farhan Tariq Janjua via discuss
 wrote:
>
> Hello,
>
> I am preparing to submit a patch that was collaboratively worked on by two 
> contributors. I would like to include both contributors' sign-offs in the 
> submission. Specifically, I am considering the following format:
>
> Signed-off-by: Author 01 Name 
> Signed-off-by: Author 02 Name 
>
> Could you please confirm if this format is acceptable for the submission 
> process? Alternatively, if there is a preferred or required procedure for 
> including multiple sign-offs (for each contributor), I would appreciate your 
> guidance on that.

Please check this out which has all the details -
https://docs.openvswitch.org/en/latest/internals/contributing/submitting-patches/

Numan

>
> Thank you for your assistance.
>
> Best,
> Fahran Tariq
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] DNAT

[Numan Siddique via discuss]

On Wed, Jul 24, 2024 at 11:15 AM Ildar Isangulov via discuss
 wrote:
>
> Hi, Justin! Sorry, didn't notice your reply
>
> I will review this
>
> Regards,
> Ildar, network engineer
>
> On Wed, Jul 24, 2024 at 6:07 PM Ildar Isangulov 
>  wrote:
>>
>> Hi Numan, thanks for your reply, here more details as you requested
>>
>> This is a structure of NAT table in the OVN NB Database in my production 
>> environment
>>
>> # ovn-nbctl --no-l list nat 
>> _uuid   :
>> allowed_ext_ips :
>> exempted_ext_ips: []
>> external_ids:
>> external_ip :
>> external_mac: []
>> external_port_range : ""
>> gateway_port: []
>> logical_ip  :
>> logical_port: []
>> options : {}
>> type:
>>
>> OVN version
>>
>> # ovn-nbctl -V
>> ovn-nbctl 24.03.2
>> Open vSwitch Library 3.3.0
>> DB Schema 7.3.0
>>
>> So, my use case is to be able to create DNAT rules like this (example):
>>
>> A user connects via public IP and some port, let's say 2, and the 
>> gateway does DNAT translation and modifies headers:
>> public IP -> private IP of VM
>> external port (2) -> ssh tcp port (22)
>>
>> But OVN can do only 1:1 DNAT translations, in other words port 2 to port 
>> 2, and this way we can expose only one VM using one public IP address
>>
>> Solution, as shown in a guide I shared demonstrates how to solve this using 
>> load balancers, but I want to try a more lightweight solution for comparison.
>>

OK. Thanks for the details.

OVN DNAT (i.e NAT of type "dnat" or "dnat_and_snat") maps one public
IP to one internal VM IP.   Seems to me using OVN load balancers is
the right way
for your use case.
i.e  PUBLIC IP : 2 = [VM1 : 22, VM2 : 22, VM3 : 22, ...]

As I said previously,  there is no real difference in the
implementation of OVN NAT and OVN Load balancers.  We use OVS
conntrack internally and it should
not have any impact in terms of performance.  Both are of the same weight.

Thanks
Numan


>> Regards,
>> Ildar, network engineer
>>
>> On Wed, Jul 24, 2024 at 5:33 PM Numan Siddique  wrote:
>>>
>>> On Wed, Jul 24, 2024 at 9:41 AM Justin Lamp via discuss
>>>  wrote:
>>> >
>>> > Hey,
>>> >
>>> > we would be in favor of that as well. It was actually possible to do
>>> > such a thing in the past, but only due to a bug, and we unfortunately
>>> > rely on that as many customers need to have ports from the routers
>>> > public ip forwarded to their VPN appliance.
>>> >
>>> > https://github.com/ovn-org/ovn/issues/233
>>> >
>>> > Thanks and best regards,
>>> > Justin Lamp
>>> >
>>> > Am 24.07.24 um 13:18 schrieb Ildar Isangulov via discuss:
>>> > > Hi everyone!
>>> > >
>>> > > I would like to ask the community about the implementation of DNAT in
>>> > > OVN. A few months ago, I read this topic
>>> > > (https://www.flaviof.com/blog2/post/main/openstack-port-forwarding/).
>>> > > Author shows how to configure DNAT translations using implementation
>>> > > with Load-balancer.
>>> > >
>>> > > My question is: is it the only one way to do DNAT in OVN? Maybe there
>>> > > is some way to configure it using either native nat rules on
>>> > > logical-router or OVS logical-flows?
>>>
>>> Hi,
>>>
>>> I'm a little confused here.  OVN does support DNAT in the logical router.
>>> Please see the NAT table in the OVN NB Database.
>>>
>>> Also note that OVN implements NAT and load balancer features using OVS
>>> conntrack.
>>> So its essentially the same underneath.
>>>
>>> Can you please explain your use case in more detail?
>>>
>>> Thanks
>>> Numan
>>>
>>> > >
>>> > > Regards,
>>> > > Ildar, network engineer
>>> > >
>>> > > ___
>>> > > discuss mailing list
>>> > > disc...@openvswitch.org
>>> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>> >
>>> >
>>> >
>>> > --
>>> > Justin Lamp
>>> > Systems Engineer
>>> >
>>> > NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
>>> > Tel: +49 911 92885-0 | Fax: +49 911 92885-77
>>> > CEO: Julian Hein, Bernd Erk, Sebastian Saemann | AG Nuernberg HRB25207
>>> > https://www.netways.de | justin.l...@netways.de
>>> >
>>> > ** Meet us at it-sa - https://www.netways.de/it-sa-2024/ **
>>> > ** OSMC 2024 - November | Nuremberg - https://osmc.de **
>>> > ** stackconf 2025 - Stay Tuned for 2025 - https://stackconf.eu **
>>> > ** NETWAYS Web Services - https://nws.netways.de **
>>> > ** NETWAYS Trainings - https://netways.de/trainings **
>>> > ___
>>> > discuss mailing list
>>> > disc...@openvswitch.org
>>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] DNAT

[Numan Siddique via discuss]

On Wed, Jul 24, 2024 at 9:41 AM Justin Lamp via discuss
 wrote:
>
> Hey,
>
> we would be in favor of that as well. It was actually possible to do
> such a thing in the past, but only due to a bug, and we unfortunately
> rely on that as many customers need to have ports from the routers
> public ip forwarded to their VPN appliance.
>
> https://github.com/ovn-org/ovn/issues/233
>
> Thanks and best regards,
> Justin Lamp
>
> Am 24.07.24 um 13:18 schrieb Ildar Isangulov via discuss:
> > Hi everyone!
> >
> > I would like to ask the community about the implementation of DNAT in
> > OVN. A few months ago, I read this topic
> > (https://www.flaviof.com/blog2/post/main/openstack-port-forwarding/).
> > Author shows how to configure DNAT translations using implementation
> > with Load-balancer.
> >
> > My question is: is it the only one way to do DNAT in OVN? Maybe there
> > is some way to configure it using either native nat rules on
> > logical-router or OVS logical-flows?

Hi,

I'm a little confused here.  OVN does support DNAT in the logical router.
Please see the NAT table in the OVN NB Database.

Also note that OVN implements NAT and load balancer features using OVS
conntrack.
So its essentially the same underneath.

Can you please explain your use case in more detail?

Thanks
Numan

> >
> > Regards,
> > Ildar, network engineer
> >
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
>
> --
> Justin Lamp
> Systems Engineer
>
> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> CEO: Julian Hein, Bernd Erk, Sebastian Saemann | AG Nuernberg HRB25207
> https://www.netways.de | justin.l...@netways.de
>
> ** Meet us at it-sa - https://www.netways.de/it-sa-2024/ **
> ** OSMC 2024 - November | Nuremberg - https://osmc.de **
> ** stackconf 2025 - Stay Tuned for 2025 - https://stackconf.eu **
> ** NETWAYS Web Services - https://nws.netways.de **
> ** NETWAYS Trainings - https://netways.de/trainings **
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] missing handler for input SB_dns - took 9062ms

[Numan Siddique via discuss]

gt; n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp,metadata=0x2c,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=346490.296s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp,metadata=0x2a5,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=346490.293s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp6,metadata=0x19f,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=346490.288s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp6,metadata=0x48,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=341492.108s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp6,metadata=0x363,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=341492.085s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp,metadata=0x363,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=70249.366s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp,metadata=0x1c1,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=70249.366s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp6,metadata=0x1c1,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=66871.739s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp6,metadata=0x347,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=66871.739s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp,metadata=0x347,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=66863.704s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp6,metadata=0x35f,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=66863.704s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp,metadata=0x360,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=66863.703s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp6,metadata=0x360,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=66863.703s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp,metadata=0x35f,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=66862.693s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp,metadata=0x357,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>  cookie=0xb2914bb, duration=66862.693s, table=32, n_packets=0,
> n_bytes=0, idle_age=65534, hard_age=65534,
> priority=100,udp6,metadata=0x357,tp_dst=53
> actions=controller(userdata=00.00.00.06.00.00.00.00.00.01.de.10.00.00.00.64,pause),resubmit(,33)
>
> On Thu, 9 May 2024 at 11:24, Gavin McKee  wrote:
> >
> > Hi Numan,
> >
> > I was just in a meeting with Han Zhou and discussed this issue.
> >
> > I am going to set always_learn_from_arp_request=false on the Logical
> > Router Port facing the localswitch (we have around 500 LR's connected
> > to that local switch).  If we age out the macs I think we should
> > reduce load and avoid learning the provider network addresses.  I am
> > just wondering if we will still learn the L3 gateway address on the
> > TOR if that is set.
> >
> >
> > Gav
> >
> > On Thu, 9 May 2024 at 11:16, Numan Siddique  wrote:
> > >
> > > On Thu, May 9, 2024 at 12:44 PM Gavin McKee via discuss
> > >  wrote

Re: [ovs-discuss] missing handler for input SB_dns - took 9062ms

[Numan Siddique via discuss]

"modify":{"timestamp":171521415}},"3b9d2f4e-c487-4c4a-9e78-27302ae03e89":{"modify":{"timestamp":171521415}},"1a0e66d4-1943-4b15-a01f-dcbe0a4d6536":{"modify":{"timestamp":171521415}},"bce17030-02ad-4682-ab31-4ff0faf36579":{"modify":{"timestamp":171521415}},"70a100aa-4454-4ae9-ac14-c413ff576e9f":{"modify":{"timestamp":171521415}},"1b681afa-1840-4954-a75b-f93fae537096":{"modify":{"timestamp":171521415}},"2a74f32b-7e11-4575-99b4-56d36eab6a30":{"modify":{"timestamp":171521415}},"fb01ee23-8ff1-456b-939f-f1edce6ea59e":{"modify":{"timestamp":171521415}},"4fd16807-3e4f-4762-805f-8001e799271a":{"modify":
> {"timestamp":171521415}},"05bf10db-a393-4f4b-a7e0-9b35b154ad87":{"modify":{"timestamp":171521415}},"2c1aeaf7-8137-471b-951e-743fe3d5121a":{"modify":{"timestamp":171521415}},"cd79c727-fe6d-485f-9549-71e4ef52f077":{"mod

Re: [ovs-discuss] missing handler for input SB_dns - took 9062ms

[Numan Siddique via discuss]

On Wed, May 8, 2024 at 6:01 PM Gavin McKee via discuss
 wrote:
>
> @Numan Siddique
>
> If we enable conditional monitoring here , will this help ?
> How does transport zones help with something like this ?  Do they
> limit the amount of processing .  We only have a single VM on this
> node , so single LSP , Logical Switch etc that is actually needed or
> used.
> Would v24.03.0 
> https://github.com/ovn-org/ovn/commit/1622526ff2102525e1bbf2ca262842c71d6b9b33
> help here ?
>

I think conditional monitoring should work as ovn-controllers will not
get updates for changes it's not interested.
You can easily test this out.  I'm not sure about the transport zones.
Even if you use transport zones,
conditional monitoring should be enabled, otherwise ovn-controller
will get updates for all SB DB changes.

I don't think the 24.03 commit you linked to would help in your case
as the issue is with ovn-controller main thread
blocking the pinctrl thread from processing the DNS packet.

Numan

> Gav
>
> On Wed, 8 May 2024 at 14:43, Gavin McKee  wrote:
> >
> > Ok so
> >
> > 1. Customers depend on the internal DNS reccords, so this is needed
> > for production operations
> > 2. I can take a look at the updates - would using conditional
> > monitoring work here?  We have ovn-monitor-all=true , would this help
> > at all ?
> > 3 & 4 . Is that something the community can help with?  Is that a
> > viable long term fix we could maybe get a patch for ?
> >
> > Gav
> >
> > On Wed, 8 May 2024 at 14:30, Numan Siddique  wrote:
> > >
> > > On Wed, May 8, 2024 at 3:20 PM Gavin McKee via discuss
> > >  wrote:
> > > >
> > > > Hi,
> > > >
> > > > Can someone help me understand why this issue occurs
> > > >
> > > >
> > > > ovn-controller 23.09.1
> > > > Open vSwitch Library 3.2.2
> > > >
> > > > We have an issue with some machines intermittently unable to resolve
> > > > DNS for external domains (example dig +noall +answer
> > > > harmonic-openai-canada.openai.azure.com)
> > > >
> > > > In the OVN controller log I see the following
> > > >
> > > > 2024-05-08T12:12:35.596Z|30138|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 7950ms
> > > > 2024-05-08T14:50:29.747Z|30312|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8634ms
> > > > 2024-05-08T14:50:46.673Z|30329|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8774ms
> > > > 2024-05-08T14:54:40.781Z|30353|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8535ms
> > > > 2024-05-08T14:58:43.381Z|30433|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8541ms
> > > > 2024-05-08T14:58:56.802Z|30488|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8820ms
> > > > 2024-05-08T15:02:50.704Z|30512|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8739ms
> > > > 2024-05-08T15:03:05.206Z|30529|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8686ms
> > > > 2024-05-08T15:08:39.441Z|30569|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 9167ms
> > > > 2024-05-08T15:09:09.152Z|30603|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8985ms
> > > > 2024-05-08T15:12:14.361Z|30632|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8569ms
> > > > 2024-05-08T15:13:52.535Z|30705|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8764ms
> > > > 2024-05-08T15:14:53.989Z|30732|inc_proc_eng|INFO|node:
> > > > logical_flow_output, recompute (missing handler for input SB_dns) took
> > > > 8802ms
> > > > 2024-05-08T15:16:30.911Z|30757|inc_proc_eng|INFO|node:
> > >

Re: [ovs-discuss] missing handler for input SB_dns - took 9062ms

[Numan Siddique via discuss]

On Wed, May 8, 2024 at 3:20 PM Gavin McKee via discuss
 wrote:
>
> Hi,
>
> Can someone help me understand why this issue occurs
>
>
> ovn-controller 23.09.1
> Open vSwitch Library 3.2.2
>
> We have an issue with some machines intermittently unable to resolve
> DNS for external domains (example dig +noall +answer
> harmonic-openai-canada.openai.azure.com)
>
> In the OVN controller log I see the following
>
> 2024-05-08T12:12:35.596Z|30138|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 7950ms
> 2024-05-08T14:50:29.747Z|30312|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8634ms
> 2024-05-08T14:50:46.673Z|30329|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8774ms
> 2024-05-08T14:54:40.781Z|30353|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8535ms
> 2024-05-08T14:58:43.381Z|30433|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8541ms
> 2024-05-08T14:58:56.802Z|30488|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8820ms
> 2024-05-08T15:02:50.704Z|30512|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8739ms
> 2024-05-08T15:03:05.206Z|30529|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8686ms
> 2024-05-08T15:08:39.441Z|30569|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 9167ms
> 2024-05-08T15:09:09.152Z|30603|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8985ms
> 2024-05-08T15:12:14.361Z|30632|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8569ms
> 2024-05-08T15:13:52.535Z|30705|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8764ms
> 2024-05-08T15:14:53.989Z|30732|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8802ms
> 2024-05-08T15:16:30.911Z|30757|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 8776ms
> 2024-05-08T15:17:09.371Z|30784|inc_proc_eng|INFO|node:
> logical_flow_output, recompute (missing handler for input SB_dns) took
> 9062ms
>
> Why would this happen and is there something I can do about it ?  Are
> there more logs needed ?

This indicates that your deployment is creating, updating or deleting a DNS row
in the Northbound database and in turn ovn-northd is updating the SB DNS rows.
When ovn-controller receives the Southbound DNS updates, it falls back
to a full recompute
because we are not handling these changes incrementally.   Since OVN
native DNS is configured
in your deployment, each DNS packet is sent to ovn-controller for lookup.
Even though a separate pinctrl thread handles packet-ins,  dns
handling is blocked until
the main ovn-controller thread releases a mutex [1].

There are a few ways to resolve this

1.  Disable native OVN DNS if you're not using this feature.  To
disable, don't create any DNS records in the OVN Northbound db.
2. Investigate why your deployment is updating the NB DBS table and
avoid it if its not required.
3.  Implement a handler for SB DNS so that ovn-controller do not fall
back to a full recompute
4.  Avoid locking on the mutex for DNS handling in pinctrl thread [1].

(3) or (4) requires code changes.

Thanks
Numan

[1] - https://github.com/ovn-org/ovn/blob/main/controller/pinctrl.c#L3807


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

Re: [ovs-discuss] NorthD inc-engine Handlers; OVN 24.03

[Numan Siddique via discuss]

On Wed, May 8, 2024 at 8:42 AM Шагов Георгий via discuss <
ovs-discuss@openvswitch.org> wrote:

> Hello everyone
>
>
>
> In some aspect it might be considered as a continuation of this thread:
> (link1), yet it is different
>
> After we have upgrade from OVN 22.03 to OVN 24.03, we have indeed found
> increase in performance in 3-4 times
>
> And yet still we do observe high CPU load for NorthD process; taking
> deeper into the logs we have found:
>
>
>

Thanks for reporting this issue.


2024-05-07T08:36:46.505Z|18503|poll_loop|INFO|wakeup due to [POLLIN] on fd
> 15 (10.34.22.66:60716<->10.34.22.66:6642) at lib/stream-fd.c:157 (94% CPU
> usage)
>
> *2024-05-07T08:37:38.857Z|18504|inc_proc_eng|INFO|node: northd, recompute
> (missing handler for input SB_datapath_binding) took 52313ms*
>
> *2024-05-07T08:37:48.335Z|18505|inc_proc_eng|INFO|node: lflow, recompute
> (failed handler for input northd) took 7759ms*
>
> *2024-05-07T08:37:48.718Z|18506|timeval|WARN|Unreasonably long 62213ms
> poll interval (56201ms user, 2900ms system)*
>
>
>
> As you can see there is a significant delay in 52 secs
>
> Correct me please, if I am in the wrong, but IMU: ‘*missing handler for*’
> – practically means absence of the inc-engine handler from some node (in
> this sample: *SB_datapath_binding*)
>

That's correct.

Before plunging into Development it would be great to clarify/adjust with
> Community’s position
>
>- Why there is not handler for this node?
>
>
Our approach has been to add a handler  for any input change only if it is
frequent or if it can be easily handled.
We also have skipped adding handlers if it increases the code complexity.
Having said that I think we are open
to adding more handlers if it makes sense or if it results in scale
improvements.

Right now we fall back to a full recompute of northd engine for any changes
to a logical switch or logical router.
Does your deployment create/delete logical switches/routers frequently ?
Is it possible to enable ovn debug logs
and share them ?  I'm curious to know what are the changes to SB datapath
binding.

Feel free to share your OVN NB and SB DBs if you're ok with it.  I can
deploy those DBs and see why recompute is so expensive.



>- Any particular reason for this or just the peculiarity of our
>installation highlighted this issue?
>
>
My guess is that your installation is frequently creating , deleting or
modifying logical switches or routers.


>-
>- Do you think there is a reason in implementing that handler? (
>*SB_datapath_binding*)
>
>
I'm fine adding a handler if it helps in the scale.   In our use cases, we
don't frequently create/delete the logical switches and routers
and hence it is ok to fall back to full recomputes for such changes.


>-
>
>
>
> Any ideas are highly appreciated.
>

You're welcome to work on it and submit patches to add a handler for
SB_datapath_binding.

@Dumitru Ceara  @Han Zhou  if you've any
reservations on adding more handlers please do comment here.

Thanks
Numan




>
> Yours truly, George
>
>
>
>
>
>- Link1:
>https://mail.openvswitch.org/pipermail/ovs-discuss/2024-March/053035.html
>
> УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: Это электронное сообщение и любые
> документы, приложенные к нему, содержат конфиденциальную информацию.
> Настоящим уведомляем Вас о том, что если это сообщение не предназначено
> Вам, использование, копирование, распространение информации, содержащейся в
> настоящем сообщении, а также осуществление любых действий на основе этой
> информации, строго запрещено. Если Вы получили это сообщение по ошибке,
> пожалуйста, сообщите об этом отправителю по электронной почте и удалите это
> сообщение.
> CONFIDENTIALITY NOTICE: This email and any files attached to it are
> confidential. If you are not the intended recipient you are notified that
> using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Does OVN support Protocol Address Translation (PAT)

[Numan Siddique via discuss]

On Wed, Mar 13, 2024 at 12:57 PM Brendan Doyle via discuss
 wrote:
>
> Hi Folks,
>
>
> Just a quick question does OVN support Protocol Address Translation (PAT)?
> I think the answer is no, but thought I'd check in case it has come in a dev
> release, and if no, are there any plans for it?

I don't think OVN supports it.  So far there have been no requests for it.
If I understand correctly we do need OVS to support this feature and I
don't think OVS supports it.
I may be wrong though.

Numan


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

Re: [ovs-discuss] OVN: Configuring Flow_Table (vswitchd.config.db) settings through OVN

[Numan Siddique via discuss]

On Wed, Mar 6, 2024 at 9:41 PM Naveen Yerramneni via discuss
 wrote:
>
>
>
> > On 07-Mar-2024, at 6:02 AM, Numan Siddique  wrote:
> >
> > On Wed, Mar 6, 2024 at 3:07 PM Naveen Yerramneni via discuss
> >  wrote:
> >>
> >> Hi All,
> >>
> >> We are exploring the possibility of doing some Flow_Table settings (like 
> >> classifier optimizations)  through OVN.
> >>
> >> One possible option could be to expose this in ovn-nb config and propagate 
> >> it to ovn-sb.
> >> - Add new table with name “Flow_Config” which stores settings (similar to 
> >> Flow_Table in  vwitchd.conf.db)
> >> - Add new columns “flow_table_in_settings” and “flow_table_out_settings” 
> >> in NB_Global and SB_Global tables.
> >>   The type of these columns is map of : where key 
> >> is logical pipeline stage number and
> >>  value points to a row entry in Flow_Config table.
> >>
> >> OVN controller uses this information and configures vwitchd.config.db.
> >> - Flow_Table rows in vswitchd.conf.db are populated using Flow_Config 
> >> table in southbound.
> >> - Bridge table's flow_tables column is populated using keys (logical table 
> >> numbers) in flow_table_in_settings and
> >>  flow_table_out_settings columns of SB_Global table . During 
> >> configuration, OVN controller adds offset
> >> OFTABLE_LOG_INGRESS_PIPELINE for ingress tables and 
> >> OFTABLE_LOG_EGRESS_PIPELINE for egress pipelines.
> >>
> >> Probably a new command can be added to northd to dump the logical switch 
> >> and logical router
> >> ingress and egress pipeline stage table names and numbers for reference.
> >>
> >> Please share your thoughts/inputs on this.
> >
> > Generally,  to configure anything which is chassis related,  we have
> > used the local openvswitch table.  Each ovn-controller would read
> > that and configure accordingly.  One example is - 
> > ovn-openflow-probe-interval.
> >
> > Can't we do something similar here ?  I understand that this config
> > needs to be done on each chassis,  but if it is a one time thing,
> > then perhaps it should not be a big concern.  Does this approach work for 
> > you ?
> >
> > Thanks
> > Numan
>
> Hi Numan,
>
> Thanks for the reply.
>
> The reason why I thought of putting this config in northbound is:
>   - Logical table numbers and physical table numbers can potentially change 
> release to release.
>   - If we have this config in northbound, it is possible to add some 
> automation in CMS plug-in to reconfigure
> the flow_table_settings on the new logical table numbers when northd gets 
> upgraded. CMS plug-in can
> have its own logic to find out the logical table numbers.
> Ex: CMS plug-in  can get the logical table numbers either by parsing the 
> northd new command
> output that dumps logical pipeline table names and numbers (or) by other 
> means.
>
>
> If the recommendation is to get this done on the chassis side then, I can 
> think of below alternative.
>   - Update northd to dump "logical pipeline stage name: logical table number” 
> in options:logical-table-mapping
> of SB_Global table.
>   - Update OVN controller to dump the "logical pipeline stage name: physical 
> table number" mapping
> to the external_ids:oftable-mapping of openvswitch table whenever SB 
> entry get updated. Additionally, we can
> possibly add to new command to ovn-controller to dump this 
> oftable-mapping.
>  - Some automation can be done on the chassis side to use the table mapping 
> information that ovn-controller dumps
>and configure the vswitchd.conf.db.
>
>
> Please let me know your suggestions.

Ok.  I was not aware of the "Flow_Table" feature of OVS.  I think it
makes sense to put the config in Northbound db
and propagate it down to OVS via ovn-controller.

This is what I think can be done:

1.  Add new Northbound tables - Switch_Pipeline_Config and
Router_Pipeline_Config.
2.  ovn-northd will create rows in these tables for each stage.
3.  CMS will set the config for each row (if it wants to)
4. ovn-northd will replicate these to Southbound db.
5. ovn-controller will aggregate the switch stage and router stage
configs since both the stages share the same table number.
6. ovn-controller will configure the OVS Flow_Table.

CMS doesn't need to know the actual physical flow table numbers.

Switch_Pipeline_Config table can have columns like

Switch_Pipeline_Config
-  name  (stage name)
-  config  (smap)


What do you think ?   It's worth taking opi

Re: [ovs-discuss] OVN: Configuring Flow_Table (vswitchd.config.db) settings through OVN

[Numan Siddique via discuss]

On Wed, Mar 6, 2024 at 3:07 PM Naveen Yerramneni via discuss
 wrote:
>
> Hi All,
>
> We are exploring the possibility of doing some Flow_Table settings (like 
> classifier optimizations)  through OVN.
>
> One possible option could be to expose this in ovn-nb config and propagate it 
> to ovn-sb.
>  - Add new table with name “Flow_Config” which stores settings (similar to 
> Flow_Table in  vwitchd.conf.db)
>  - Add new columns “flow_table_in_settings” and “flow_table_out_settings” in 
> NB_Global and SB_Global tables.
>The type of these columns is map of : where key is 
> logical pipeline stage number and
>   value points to a row entry in Flow_Config table.
>
> OVN controller uses this information and configures vwitchd.config.db.
>  - Flow_Table rows in vswitchd.conf.db are populated using Flow_Config table 
> in southbound.
>  - Bridge table's flow_tables column is populated using keys (logical table 
> numbers) in flow_table_in_settings and
>   flow_table_out_settings columns of SB_Global table . During configuration, 
> OVN controller adds offset
>  OFTABLE_LOG_INGRESS_PIPELINE for ingress tables and 
> OFTABLE_LOG_EGRESS_PIPELINE for egress pipelines.
>
> Probably a new command can be added to northd to dump the logical switch and 
> logical router
> ingress and egress pipeline stage table names and numbers for reference.
>
> Please share your thoughts/inputs on this.

Generally,  to configure anything which is chassis related,  we have
used the local openvswitch table.  Each ovn-controller would read
that and configure accordingly.  One example is - ovn-openflow-probe-interval.

Can't we do something similar here ?  I understand that this config
needs to be done on each chassis,  but if it is a one time thing,
then perhaps it should not be a big concern.  Does this approach work for you ?

Thanks
Numan

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

Re: [ovs-discuss] OVN : Resiliency and bindings question

[Numan Siddique via discuss]

On Wed, Dec 13, 2023 at 4:23 AM Vincent Godin via discuss
 wrote:
>
> Hi Numan,
>
> Thanks for your help !
>
> As you said in norhd.log :
>
> 2023-12-13T09:06:05.907Z|00017|northd|WARN|NAT is configured on logical 
> router neutron-1a8201e0-154d-4d53-a3b3-d8cae9607e36, which has 2 distributed 
> gateway ports. NAT is not supported yet when there is more than one 
> distributed gateway port on the router.
>
> I will try to find a neutron plugin compatible with ovn 22.06 !
>
> Last question (sorry) ...

No worries.


>
> Is there a command to check the status of geneve tunnel ? I'd like to be sure 
> (on a other PoC) that tunnels are in good state. With "ovs-vsctl show", 
> sometime i have a BFD status and sometime none ...

This may not be possible unless you have configured gateway_chassis or
HA Chassis group.Please see below

>
> sample  :
>  Bridge br-int
>  fail_mode: secure
>  datapath_type: system
>  Port ovn-9e9101-1
>  Interface ovn-9e9101-1
>  type: geneve
>  options: {csum="true", key=flow, remote_ip="172.16.11.2"}
>  Port br-int
>  Interface br-int
>  type: internal
>  Port ovn-0527de-1
>  Interface ovn-0527de-1
>  type: geneve
>  options: {csum="true", key=flow, remote_ip="172.16.21.3"}
>  Port tap8d388975-10
>  Interface tap8d388975-10
>  Port ovn-9e963a-1
>  Interface ovn-9e963a-1
>  type: geneve
>  options: {csum="true", key=flow, remote_ip="172.16.11.3"}
>  bfd_status: {diagnostic="No Diagnostic", flap_count="1", 
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up, 
> state=up}
>  Port patch-br-int-to-provnet-a384e581-3e54-4e75-8219-193f8fcdcd70
>  Interface 
> patch-br-int-to-provnet-a384e581-3e54-4e75-8219-193f8fcdcd70
>  type: patch
>  options: 
> {peer=patch-provnet-a384e581-3e54-4e75-8219-193f8fcdcd70-to-br-int}
>  Port tap8b0fa59b-96
>  Interface tap8b0fa59b-96
>  ovs_version: "2.17.8"
>
> Why is there a BFD status for Port ovn-9e963a-1 and none for Port 
> ovn-9e9101-1 or Port ovn-0527de-1 ?

Please take a look at this -
https://docs.ovn.org/en/latest/topics/high-availability.html

It has some details.

To briefly describe,  OVN uses BFD feature provided by OVS to
implement the active-passive HA for distributed gateway ports (with
gateway_chassis or HA Chassis group) configured.

Lets say If a distributed gateway port - lrp-public is configured with
a 3 gateway chassis - gw-1 (with priority 50), gw-2 (40) and gw-3(30),
 then OVN configures BFD on the tunnel interfaces
on chassis gw-1  for gw-2 and gw-3.   If there are other chassis in
the deployment - hv1, hv2,  OVN doesn't configure BFD from
gw-1/gw-2/gw-3 to hv1 and hv2 unless it is required.
That's why you see BFD status on some ports and not on others.

Since gw-1 has highest priority it will be the master gateway for the
router port - "lrp-public".  If you run "ovn-sbctl show" you will see
a port "cr- claimed by the master chassis.
If for some reason gw-1 is down, then it is detected by OVN and the
next gw chassis - gw-2 will be promoted to master.

Thanks
Numan




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

Re: [ovs-discuss] OVN : Resiliency and bindings question

[Numan Siddique via discuss]

action=(eth.dst = fa:16:3e:70:82:6e; next;)
>   table=15(lr_in_arp_resolve  ), priority=100  , match=(outport == "to-sw-ts" 
> && reg0 == 169.254.100.2), action=(eth.dst = aa:aa:aa:aa:aa:02; next;)
>   table=15(lr_in_arp_resolve  ), priority=1, match=(ip4.dst == 
> {172.16.10.181}), action=(drop;)
>   table=15(lr_in_arp_resolve  ), priority=0, match=(ip4), 
> action=(get_arp(outport, reg0); next;)
>   table=15(lr_in_arp_resolve  ), priority=0, match=(ip6), 
> action=(get_nd(outport, xxreg0); next;)
>   table=16(lr_in_chk_pkt_len  ), priority=0, match=(1), action=(next;)
>   table=17(lr_in_larger_pkts  ), priority=0, match=(1), action=(next;)
>   table=18(lr_in_gw_redirect  ), priority=50   , match=(outport == 
> "lrp-a96d7d78-c3a6-487e-91bc-10e97ccb3d9d"), action=(outport = 
> "cr-lrp-a96d7d78-c3a6-487e-91bc-10e97ccb3d9d"; next;)
>   table=18(lr_in_gw_redirect  ), priority=50   , match=(outport == 
> "to-sw-ts"), action=(outport = "cr-to-sw-ts"; next;)
>   table=18(lr_in_gw_redirect  ), priority=0, match=(1), action=(next;)
>   table=19(lr_in_arp_request  ), priority=100  , match=(eth.dst == 
> 00:00:00:00:00:00 && ip4), action=(arp { eth.dst = ff:ff:ff:ff:ff:ff; arp.spa 
> = reg1; arp.tpa = reg0; arp.op = 1; output; };)
>   table=19(lr_in_arp_request  ), priority=100  , match=(eth.dst == 
> 00:00:00:00:00:00 && ip6), action=(nd_ns { nd.target = xxreg0; output; };)
>   table=19(lr_in_arp_request  ), priority=0, match=(1), action=(output;)
> Datapath: "neutron-d3cbe671-46a9-4596-a3d3-95882ed318b7" aka "lr-1" 
> (8f5d574a-c41d-4fba-a835-b8375a96f7db)  Pipeline: egress
>   table=0 (lr_out_chk_dnat_local), priority=0, match=(1), action=(reg9[4] 
> = 0; next;)
>   table=1 (lr_out_undnat  ), priority=0, match=(1), action=(next;)
>   table=2 (lr_out_post_undnat ), priority=0, match=(1), action=(next;)
>   table=3 (lr_out_snat), priority=120  , match=(nd_ns), action=(next;)
>   table=3 (lr_out_snat), priority=0, match=(1), action=(next;)
>   table=4 (lr_out_post_snat   ), priority=0, match=(1), action=(next;)
>   table=5 (lr_out_egr_loop), priority=0, match=(1), action=(next;)
>   table=6 (lr_out_delivery), priority=100  , match=(outport == 
> "lrp-4eac4d9c-7de5-4f81-a73d-1bf44e312f73"), action=(output;)
>   table=6 (lr_out_delivery), priority=100  , match=(outport == 
> "lrp-a96d7d78-c3a6-487e-91bc-10e97ccb3d9d"), action=(output;)
>   table=6 (lr_out_delivery), priority=100  , match=(outport == 
> "to-sw-ts"), action=(output;)
>
>

Looks ovn-northd is not able to figure out which logical port to use
for the NATs.  Can you please check the ovn-northd logs and see any
warnings ?

I'm pretty sure there should be some.  Also since the logical router
has multiple gateway router ports in your case,  you need to set the
gateway_port for each NAT entry.  But you seem to be missing a column
"gateway_port" in the NAT table.  Which means you're using an older
version.

Check this commit out this commit -
https://github.com/ovn-org/ovn/commit/2d942be7db1799f2778492331513ae2b5a556b92

You need to use OVN version 22.06 or higher to have NAT support in the
logical routers which have multiple gateway ports.
Once you've it,  you can set the gateway_port for the NAT as

ovn-nbctl set NAT 612c64ff-a593-42eb-bce4-b99f38c442c4
gateway_port=

or

 ovn-nbctl --gateway-port=lrp-a96d7d78-c3a6-487e-91bc-10e97ccb3d9d
lr-nat-add lr-1 snat  172.16.10.18110.0.1.0/24

Thanks
Numan




> ovn-nbctl list logical_router lr-1
>
> root@dc-1-hyp01:~# ovn-nbctl list logical_router 
> neutron-d3cbe671-46a9-4596-a3d3-95882ed318b7
> _uuid   : 45178303-bd0e-40f1-b0db-b6508d6a491e
> copp: []
> enabled : true
> external_ids: {"neutron:availability_zone_hints"="", 
> "neutron:gw_network_id"="fd415705-6cd5-4ea0-9864-d4b1dd9f789d", 
> "neutron:gw_port_id"="a96d7d78-c3a6-487e-91bc-10e97ccb3d9d", 
> "neutron:revision_number"="8", "neutron:router_name"=lr-1}
> load_balancer   : []
> load_balancer_group : []
> name: neutron-d3cbe671-46a9-4596-a3d3-95882ed318b7
> nat : [612c64ff-a593-42eb-bce4-b99f38c442c4]
> options : {always_learn_from_arp_request="false", 
> dynamic_neigh_routers="true"}
> policies: []
> ports   : [13790dbe-d9bd-44ad-8aa2-03734d4e7509, 
> 43bf5ede-62f5-40bd-b623-49aaf6a6b765, 7429480d-98a7-48d3-8a03-70b5cb8cd76a]
> static_routes   : [22114c67-e3c3-4a14-bd42-9e53a00e94dd, 
> 5d1d9a3b-b5a1-4474-a4b0-70d0

Re: [ovs-discuss] OVN : Resiliency and bindings question

[Numan Siddique via discuss]

Thanks for sharing the logs.  Looks like there are no NATs configured.

Can you please share the o/p of  "ovn-sbctl dump-flows lr-1",
"ovn-nbctl list logical_router lr-1"  and "ovn-nbctl list NAT"


Thanks
Numan

On Tue, Dec 12, 2023 at 8:11 AM Vincent Godin via discuss
 wrote:
>
> Thank you very much Numan !
>
> I will try with HA Chassis Group
>
> For the snat problem, let me give you more informations :
>
> on lr-1 :
>
> root@dc-1-hyp01:~# ovn-nbctl lr-route-list 
> neutron-d3cbe671-46a9-4596-a3d3-95882ed318b7
> IPv4 Routes
> Route Table :
>   10.0.2.0/24 169.254.100.2 dst-ip
> 0.0.0.0/0   172.16.10.1 dst-ip
>
> root@dc-1-hyp01:~# ovn-nbctl lr-nat-list 
> neutron-d3cbe671-46a9-4596-a3d3-95882ed318b7
> TYPE EXTERNAL_IPEXTERNAL_PORTLOGICAL_IP
> EXTERNAL_MAC LOGICAL_PORT
> snat 172.16.10.181   10.0.1.0/24
>
> on lr-2 :
>
> root@dc-2-hyp01:~# ovn-nbctl lr-route-list 
> neutron-b761e5e4-7327-4cdf-b1d0-97c267fd52d7
> IPv4 Routes
> Route Table :
>   10.0.1.0/24 169.254.100.1 dst-ip
> 0.0.0.0/0   172.16.20.1 dst-ip
>
> If i trace a icmp echo from the vm-1 (10.0.1.188) to the external gateway 
> (172.16.10.1)
>
> root@dc-1-hyp01:~# ovn-trace --detail 
> neutron-8d388975-101b-4c6f-8ae4-1f6f429c22f6 'inport == 
> "8b0fa59b-962d-4848-96e8-6b64bb483a56" && eth.src == fa:16:3e:c4:b1:69 && 
> eth.dst == fa:16:3e:52:95:fd && ip4.src == 10.0.1.188 && ip4.dst == 
> 172.16.10.1 && ip.ttl == 32 && icmp4.type == 8'
> # 
> icmp,reg14=0x3,vlan_tci=0x,dl_src=fa:16:3e:c4:b1:69,dl_dst=fa:16:3e:52:95:fd,nw_src=10.0.1.188,nw_dst=172.16.10.1,nw_tos=0,nw_ecn=0,nw_ttl=32,nw_frag=no,icmp_type=8,icmp_code=0
>
> ingress(dp="net-1", inport="8b0fa5")
> 
>  0. ls_in_port_sec_l2 (northd.c:5652): inport == "8b0fa5" && eth.src == 
> {fa:16:3e:c4:b1:69}, priority 50, uuid 6b1602aa
> next;
>  1. ls_in_port_sec_ip (northd.c:5285): inport == "8b0fa5" && eth.src == 
> fa:16:3e:c4:b1:69 && ip4.src == {10.0.1.188}, priority 90, uuid 95750115
> next;
>  5. ls_in_pre_acl (northd.c:5915): ip, priority 100, uuid 95d1a153
> reg0[0] = 1;
> next;
>  7. ls_in_pre_stateful (northd.c:6095): reg0[0] == 1, priority 100, uuid 
> c49352e8
> ct_next;
>
> ct_next(ct_state=est|trk /* default (use --ct to customize) */)
> ---
>  8. ls_in_acl_hint (northd.c:6183): !ct.new && ct.est && !ct.rpl && 
> ct_label.blocked == 0, priority 4, uuid 5ca5c0f2
> reg0[8] = 1;
> reg0[10] = 1;
> next;
>  9. ls_in_acl (northd.c:6425): reg0[8] == 1 && (inport == 
> @pg_b607165d_a4f0_4e04_adf3_20e37b08d39b && ip4 && ip4.dst == 0.0.0.0/0), 
> priority 2002, uuid 140ab284
> next;
> 24. ls_in_l2_lkup (northd.c:8697): eth.dst == fa:16:3e:52:95:fd, priority 50, 
> uuid aff910da
> outport = "4eac4d";
> output;
>
> egress(dp="net-1", inport="8b0fa5", outport="4eac4d")
> -
>  0. ls_out_pre_acl (northd.c:5802): ip && outport == "4eac4d", priority 110, 
> uuid f40a6c28
> next;
>  1. ls_out_pre_lb (northd.c:5802): ip && outport == "4eac4d", priority 110, 
> uuid 62d9a6b5
> next;
>  3. ls_out_acl_hint (northd.c:6183): !ct.new && ct.est && !ct.rpl && 
> ct_label.blocked == 0, priority 4, uuid e20482b0
> reg0[8] = 1;
> reg0[10] = 1;
> next;
>  9. ls_out_port_sec_l2 (northd.c:5749): outport == "4eac4d", priority 50, 
> uuid 2a82f83d
> output;
> /* output to "4eac4d", type "patch" */
>
> ingress(dp="lr-1", inport="lrp-4eac4d")
> ---
>  0. lr_in_admission (northd.c:10984): eth.dst == fa:16:3e:52:95:fd && inport 
> == "lrp-4eac4d", priority 50, uuid 980d0e4c
> xreg0[0..47] = fa:16:3e:52:95:fd;
> next;
>  1. lr_in_lookup_neighbor (northd.c:11147): 1, priority 0, uuid 9a8072c7
> reg9[2] = 1;
> next;
>  2. lr_in_learn_neighbor (northd.c:11156): reg9[2] == 1 || reg9[3] == 0, 
> priority 100, uuid 00d01e41
> next;
> 10. lr_in_ip_routing_pre (northd.c:11382): 1, priority 0, uuid ea5d4e99
> reg7 = 0;
> next;
> 11. lr_in_ip_routing (northd.c:9861): ip4.dst == 172.16.10.0/24, priority 74, 
> uuid d7f6b4a7
> ip.ttl--;
> reg8[0..15] = 0;
> reg0 = ip4.dst;
> reg1 = 172.16.10.181;
> eth.src = fa:16:3e:38:56:0b;
> outport = "lrp-a96d7d";
> flags.loopback = 1;
> next;
> 12. lr_in_ip_routing_ecmp (northd.c:11458): reg8[0..15] == 0, priority 150, 
> uuid c21651eb
> next;
> 13. lr_in_policy (northd.c:11592): 1, priority 0, uuid 9f549b6b
> reg8[0..15] = 0;
> next;
> 14. lr_in_policy_ecmp (northd.c:11594): reg8[0..15] == 0, priority 150, uuid 
> e4edbcc2
> next;
> 15. lr_in_arp_resolve (northd.c:11628): ip4, priority 0, uuid 9f8d9d70
> get_arp(outport, reg0);
> /* MAC binding to 52:54:00:7c:33:5f. */
> next

Re: [ovs-discuss] OVN : Resiliency and bindings question

[Numan Siddique via discuss]

On Sun, Dec 10, 2023 at 8:30 AM Vincent Godin via discuss
 wrote:
>
> Hello,
>
> I attached a drawing of the infrastructure
>
> > To get a clearer understanding of the toplogy,  is it possible to share the 
> > output of "ovn-nbctl show"  of your 3 DCs ?
>
> On DC-1
>
> root@dc-1-hyp01:~# ovn-nbctl show
> switch 475972cc-f73b-49a4-8551-f1a89a1e48a5 
> (neutron-fd415705-6cd5-4ea0-9864-d4b1dd9f789d) (aka provider-1)
> port a96d7d78-c3a6-487e-91bc-10e97ccb3d9d
> type: router
> router-port: lrp-a96d7d78-c3a6-487e-91bc-10e97ccb3d9d
> port provnet-a384e581-3e54-4e75-8219-193f8fcdcd70
> type: localnet
> addresses: ["unknown"]
> port ce1768b3-2da9-4160-97b8-89e1315cc870
> type: localport
> addresses: ["fa:16:3e:70:82:6e 172.16.10.100"]
> switch b185ef2e-1a56-4a62-bd88-34527b092a27 (sw-ts)
> port to-lr-1
> type: router
> router-port: to-sw-ts
> port to-lr-2
> type: remote
> addresses: ["aa:aa:aa:aa:aa:02 169.254.100.2/24"]
> switch 31e35f66-2fe7-4868-9bc0-8defcf937de3 
> (neutron-8d388975-101b-4c6f-8ae4-1f6f429c22f6) (aka net-1)
> port 8b0fa59b-962d-4848-96e8-6b64bb483a56
> addresses: ["fa:16:3e:c4:b1:69 10.0.1.188"]
> port 4eac4d9c-7de5-4f81-a73d-1bf44e312f73
> type: router
> router-port: lrp-4eac4d9c-7de5-4f81-a73d-1bf44e312f73
> port 9317e6a9-6c00-4797-8cc9-d14ac35d3fa6
> type: localport
> addresses: ["fa:16:3e:51:5a:4d 10.0.1.2"]
> router 45178303-bd0e-40f1-b0db-b6508d6a491e 
> (neutron-d3cbe671-46a9-4596-a3d3-95882ed318b7) (aka lr-1)
> port to-sw-ts
> mac: "aa:aa:aa:aa:aa:01"
> networks: ["169.254.100.1/24"]
> gateway chassis: [9e963afb-b823-49f0-bb2a-7a55ffb27c62 
> 1fec4429-b7e8-445a-a6ef-86bae79822a6]
> port lrp-4eac4d9c-7de5-4f81-a73d-1bf44e312f73
> mac: "fa:16:3e:52:95:fd"
> networks: ["10.0.1.1/24"]
> port lrp-a96d7d78-c3a6-487e-91bc-10e97ccb3d9d
> mac: "fa:16:3e:38:56:0b"
> networks: ["172.16.10.181/24"]
> gateway chassis: [1fec4429-b7e8-445a-a6ef-86bae79822a6 
> 9e963afb-b823-49f0-bb2a-7a55ffb27c62]
> nat 612c64ff-a593-42eb-bce4-b99f38c442c4
> external ip: "172.16.10.181"
> logical ip: "10.0.1.0/24"
> type: "snat"
>
> On DC-2
>
> root@dc-2-hyp01:~# ovn-nbctl show
> switch c506d9c0-0503-4c85-b8af-00f8e89407c2 
> (neutron-80badf16-5ea3-4c63-8d23-d8f69b7bc661) (aka net-2)
> port 0e11f6d3-c1b6-4acf-b34d-9027bc79d802
> type: localport
> addresses: ["fa:16:3e:e1:55:a4 10.0.2.2"]
> port edceb0d3-7c8d-427f-a0ea-fd3712fc6c4d
> type: router
> router-port: lrp-edceb0d3-7c8d-427f-a0ea-fd3712fc6c4d
> port d4d9dc88-ea9e-4d80-b518-c271689dee48
> addresses: ["fa:16:3e:c3:cd:32 10.0.2.195"]
> switch 8019d393-65ac-46b1-9a51-e34afea6ecba 
> (neutron-e19b0890-61e1-402a-b4e5-434bdfbc75b0) (aka provider-2)
> port 941a8243-afa0-4f2d-abb1-2eddadd2a47a
> type: router
> router-port: lrp-941a8243-afa0-4f2d-abb1-2eddadd2a47a
> port 60fad924-22f8-48f1-b85e-b5b63b3a3beb
> type: localport
> addresses: ["fa:16:3e:8f:72:94 172.16.20.100"]
> port provnet-200da922-d22c-477b-9307-bc599d0307de
> type: localnet
> addresses: ["unknown"]
> switch 1d8daf77-3636-4cce-96aa-e944ae5fe1aa (sw-ts)
> port to-lr-1
> type: remote
> addresses: ["aa:aa:aa:aa:aa:01 169.254.100.1/24"]
> port to-lr-2
> type: router
> router-port: to-sw-ts
> router 33aee57e-beea-4347-9060-d70031e74d5c 
> (neutron-b761e5e4-7327-4cdf-b1d0-97c267fd52d7) (aka lr-2)
> port to-sw-ts
> mac: "aa:aa:aa:aa:aa:02"
> networks: ["169.254.100.2/24"]
> gateway chassis: [0527de7d-76e2-44c3-a35a-23f92336b662]
> port lrp-edceb0d3-7c8d-427f-a0ea-fd3712fc6c4d
> mac: "fa:16:3e:d9:b4:58"
> networks: ["10.0.2.1/24"]
> port lrp-941a8243-afa0-4f2d-abb1-2eddadd2a47a
> mac: "fa:16:3e:29:b4:65"
> networks: ["172.16.20.185/24"]
> gateway chassis: [0527de7d-76e2-44c3-a35a-23f92336b662]
> nat 6032cda0-5d42-406c-b3ba-c6a06727f02e
> external ip: "172.16.20.185"
> logical ip: "10.0.2.0/24"
> type: "snat"
>
> From vm-1 with ip 10.0.1.188, i should ping the outside gateway 172.16.10.1 
> (with a snat applied) and vm-2 on DC-2 10.0.2.195 via a geneve tunnel
>
> The original question was about the colocalization of port bingings 
> lrp-941a8243-afa0-4f2d-abb1-2eddadd2a47a and to-sw-ts on the same chassis ... 
> I'd like them to be tight together on the same chassis in case of a failure
>
> But as I tried to reproduce this case for you, I realise that no snat occurs 
> when vm-1 or vm-2 try to contact their external router (respectively 
> 172.16.10.1 and 172.16.20.1). I can see pacquets outgoing but without nat !!!
> On the other hand, vm-1 is able to contact vm-2
>
> 1 - Why snat is not applied ???

From the

Re: [ovs-discuss] OVN : Resiliency and bindings question

[Numan Siddique via discuss]

On Thu, Dec 7, 2023 at 9:49 AM Vincent Godin via discuss
 wrote:
>
> First, let's explain my design
>
> 3 OVN, 1 on each site DC1, DC2 and DC3
> On each OVN :
> - one subnet with only one vm per DC (let's call them subnet-1 and
> vm-1 on DC1, subnet-2 and vm-2 on DC2 and subnet-3 and vm-3 on DC3)
> - each subnet is able to connect the external world with a provider
> network, provider-1 on DC1, provider-2 on DC2, ...
> - each subnet is able to connect to the others subnets via an OVN
> Interconnect transit switch : sw-ts
>
> On OVN-1, i have :
> a sw-1 for the subnet-1 attached to vm-1 and lr-1
> a lr-1 :
>   attached to sw-1 and set as default gateway for subnet-1
>   attached to sw-ts with ip1
>   configured with a default gateway set to provider-1
>   configured to route subnet-2 to ip2 (IP address of lr-2
> port-to-sw-ts on DC2) and subnet-3 to ip3 (IP address of lr-3
> port-to-sw-ts on DC3)
> a sw-ts :
>   attached locally to lr1 et remotely to lr2 and lr3 on
> respectively DC2 and DC3
>
> With this design :
>   vm-1 is able to connect to vm-2 on DC2 and to vm-3 on DC3.
>   vm-1 is able to connect to the external world via provider-1
> (with a SNAT on lr-1)
>
> For lr-1, i will to have two bindings :
>   one for the OVN-IC connectivity to fix the node it will use to
> connect the others node on DC2 and DC3
>   one for the external connectivity to fix the node it will use to
> connect to the provider network
>
> If I have one network node on DC1, the two bindings for lr-1 will be
> set on it (with the good configuration of course)
> If I have two network nodes on DC1, i need to set the priority the
> same way on the two bindings for them to stay on the same network node
>
> If the "master" node loose its inter-DC connectivity, the "OVN-IC"
> binding will change to the second node but the "external" binding will
> stay on the master node : vm-1 can not anymore connect the other vms
> on DC2 or DC3 !!!

To get a clearer understanding of the toplogy,  is it possible to
share the output of "ovn-nbctl show"  of your 3 DCs ?

What do you mean by bindings on lr-1 ?  You mean logical router ports
with gateway chassis set to it ?

Thanks
Numan

>
> Is there a way to "group" bindings so that they will be tight together
> ? If one must change of node, the other will change to the same node
>
> Thank you for your help
>
> Vincent
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN/OVS Provider Bridge / BGP Agent

[Numan Siddique via discuss]

On Tue, Nov 7, 2023 at 12:04 PM Gavin McKee via discuss
 wrote:
>
> Hi ,
>
> We need to scale DNAT address learning and have found G-ARP to be a
> continual issue for us.
>
> We have some hypervisors that can host up to 100+ Logical Switch Ports
> bound to SR-IOV functions.  The CoPP on the Top of Rack switch may
> under some conditions (like large numbers of VIF being inserted into
> the br-int bridge - could cause GARP to flood the switch and therefore
> the CoPP drops the frame).
>

We recently added an option to send GARPs periodically instead of a
burst of GARPs and then stopping altogether.
The commit is here -
https://github.com/ovn-org/ovn/commit/0d021216cf43911bb9a7afa8bec90993a3231b0e

Maybe you can check this out and see if it solves your problem.

Thanks
Numan


> I am thinking about moving to a BGP based approach that triggers the
> creation of an EVPN Type 5 route in our data center fabric but using a
> local GoBGP agent and triggering address creation over a GRPC call.
>
> Today our topology is simple:
> We use a localnet port with a vlan120 tag in a provider bridge called
> br-provider, which extends L2 from the hypervisor to the TOR.  The TOR
> has a L3 interface for Vlan120 , with any anycast gateway ,
> 172.16.0.1, all logical routers have a 0/0 route pointing to
> 172.16.0.1.  When the OVN controller sends a G-ARP the EVPN ARP
> snooping generates a Type 2 EVPN route and sends a /32 route for the
> DNAT to our fabric / WAN border.  When the GARP is sent and address
> learning is completed , everything works well , it just sometimes we
> either don't see a GARP from the OVN controller or we are hitting the
> CoPP limit.
>
> What I would like to do is as follows:
> Add a new BGP peering between the Hypervisor and the TOR , this will
> be on a new VIF called bgp-peering-if and be tagged with vlan5 , my
> lab case will have p2p peering with the TOR on 192.168.55.0/31
> Terminate the L3 interface for VLAN120 on each hypervisor i.e. add an
> interface called ovn-localnet-if to the provider bridge, this
> interface will have 172.16.0.1 (the GW for Vlan120).
>
> Here is where I'm struggling.
>
> If traffic moves from a customer overlay into the provider bridge ,
> should it be on a localnet port , localport or externalport .
> I don't have L3 routing on the br-provider bridge - if I do then I
> need to make a routing decision to send traffic to 0/0 via the BGP
> next hop.  If I do this will the offload fail and the kernel route the
> packet ? (I'm using the CX6 card with HW offload enabled).
>
> Return traffic , how will the traffic returning from the physical
> network be handled by the br-provider bridge ?  In the packet capture
> below I am showing traffic routing from the internet to my lab host
> 91.106.221.181 , you can see the traffic come in on the physical
> interface with vlan tag = 5 , my BGP peering interface
>
> 16:58:38.078660 9c:05:91:22:e2:fd > 72:58:a5:8f:1b:65, ethertype
> 802.1Q (0x8100), length 102: vlan 5, p 0, ethertype IPv4 (0x0800),
> (tos 0x0, ttl 45, id 49114, offset 0, flags [none], proto ICMP (1),
> length 84)
> 50.175.168.194 > 91.106.221.181: ICMP echo request, id 30241, seq
> 18, length 64
>
> Somehow I need the provider bridge to send this traffic into a
> customer overlay .
>
> Can anyone comment on this approach ? If it seems viable , should I be
> writing openflow rules for the provider bridge to handle this scenario
> ?
>
> Thanks
>
> Gav
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS OVN upgrade

[Numan Siddique via discuss]

On Mon, Nov 13, 2023 at 7:16 PM Sri kor via discuss
 wrote:
>
>
> Hi Team,
>I am on Rocky linux version 9.1. I have installed the 
> centos-nfv-openvswitch package repo. When I tried to install /upgrade 
> ovn-controller, the latest version I could see was 23.06. But 23.09 is out 
> and probably not available in this repo. Do we have any package repo to get 
> the 23.09 version?

You may check with the rocky linux package maintainers ?

OVN 23.09 is  available in Fedora.  If you want OVN 23.09, you may
have to generate packages yourself using "make rpm-fedora".

>
> When I upgraded my ovs-vswitchd from 2.17.6 to 3.2.0($ dnf install  
> openvswitch3.2.x86_64 --allowerasing), the ovn-controller died. I had to 
> restart the ovn-controller service manually. Is it expected ? Any workaround?
That's odd.  It should not die.  Not sure what's going on.  Can you
reproduce it by enabling ovn-controller debug logs (ovn-appctl -t
ovn-controller vlog/set dbg)
and then upgrading ovs-vswitchd ?  If so, please try that and share
the ovn-controller debug logs.


Thanks
Numan

>
> $ cat /etc/os-release
> NAME="Rocky Linux"
> VERSION="9.1 (Blue Onyx)"
> ID="rocky"
> ID_LIKE="rhel centos fedora"
> VERSION_ID="9.1"
> PLATFORM_ID="platform:el9"
> PRETTY_NAME="Rocky Linux 9.1 (Blue Onyx)"
> ANSI_COLOR="0;32"
> LOGO="fedora-logo-icon"
> CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
> HOME_URL="https://rockylinux.org/";
> BUG_REPORT_URL="https://bugs.rockylinux.org/";
> ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
> ROCKY_SUPPORT_PRODUCT_VERSION="9.1"
> REDHAT_SUPPORT_PRODUCT="Rocky Linux"
> REDHAT_SUPPORT_PRODUCT_VERSION="9.1"
> $ dnf search ovn
> Last metadata expiration check: 1:36:37 ago on Mon 13 Nov 2023 10:22:31 PM 
> UTC.
> = Name Matched: ovn 
> ==
> ovn-2021.x86_64 : Open Virtual Network support
> ovn-2021-central.x86_64 : Open Virtual Network support
> ovn-2021-host.x86_64 : Open Virtual Network support
> ovn-2021-vtep.x86_64 : Open Virtual Network support
> ovn22.03.x86_64 : Open Virtual Network support
> ovn22.03-central.x86_64 : Open Virtual Network support
> ovn22.03-host.x86_64 : Open Virtual Network support
> ovn22.03-vtep.x86_64 : Open Virtual Network support
> ovn22.06.x86_64 : Open Virtual Network support
> ovn22.06-central.x86_64 : Open Virtual Network support
> ovn22.06-host.x86_64 : Open Virtual Network support
> ovn22.06-vtep.x86_64 : Open Virtual Network support
> ovn22.09.x86_64 : Open Virtual Network support
> ovn22.09-central.x86_64 : Open Virtual Network support
> ovn22.09-host.x86_64 : Open Virtual Network support
> ovn22.09-vtep.x86_64 : Open Virtual Network support
> ovn22.12.x86_64 : Open Virtual Network support
> ovn22.12-central.x86_64 : Open Virtual Network support
> ovn22.12-host.x86_64 : Open Virtual Network support
> ovn22.12-vtep.x86_64 : Open Virtual Network support
> ovn23.03.x86_64 : Open Virtual Network support
> ovn23.03-central.x86_64 : Open Virtual Network support
> ovn23.03-host.x86_64 : Open Virtual Network support
> ovn23.03-vtep.x86_64 : Open Virtual Network support
> ovn23.06.x86_64 : Open Virtual Network support
> ovn23.06-central.x86_64 : Open Virtual Network support
> ovn23.06-host.x86_64 : Open Virtual Network support
> ovn23.06-vtep.x86_64 : Open Virtual Network support
> Current version
>
>  /$ ovsdb-server --version
> ovsdb-server (Open vSwitch) 3.2.2
> /$ ovs-vswitchd --version
> ovs-vswitchd (Open vSwitch) 3.2.2
> DPDK 22.11.1
>  /$ ovn-controller --version
> ovn-controller 23.06.2
> Open vSwitch Library 3.1.1
> OpenFlow versions 0x6:0x6
> SB DB Schema 20.27.2
>
> thanks
> Srini
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN: CARP not working

[Numan Siddique via discuss]

On Wed, Oct 18, 2023 at 3:19 AM Justin Lamp via discuss
 wrote:
>
> Hi,
>
> thanks for the reply. Indeed when I delete the virtual port and set the 
> addresses to unknown the vip becomes reachable and failover works as well. 
> The problem is that after a couple of seconds all traffic will be dropped 
> again.
> External traffic, though, still works (I have a Floating IP attached), but 
> that might be some traffic coming in that will keep the flows in the kernel.

I'd suggest testing with only "unknown" set instead of
["fa:16:3e:61:76:50 100.64.56.252", unknown] for both the virtual
parents.

Thanks
Numan

>
> ubuntu@tester:~$ ping 100.64.56.254
> PING 100.64.56.254 (100.64.56.254) 56(84) bytes of data.
> 64 bytes from 100.64.56.254: icmp_seq=1 ttl=63 time=1.08 ms
> 64 bytes from 100.64.56.254: icmp_seq=2 ttl=63 time=0.859 ms
> 64 bytes from 100.64.56.254: icmp_seq=3 ttl=63 time=0.765 ms
> 
> 64 bytes from 100.64.56.254: icmp_seq=7 ttl=64 time=1.90 ms
> 64 bytes from 100.64.56.254: icmp_seq=8 ttl=64 time=0.516 ms
> 64 bytes from 100.64.56.254: icmp_seq=9 ttl=64 time=0.203 ms
> ^C
> --- 100.64.56.254 ping statistics ---
> 9 packets transmitted, 6 received, 33.% packet loss, time 8100ms
> rtt min/avg/max/mdev = 0.203/0.887/1.901/0.530 ms
> ubuntu@tester:~$ sleep 5
> ubuntu@tester:~$ ping 100.64.56.254
> PING 100.64.56.254 (100.64.56.254) 56(84) bytes of data.
> ^C
> --- 100.64.56.254 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 3065ms
>
> ubuntu@tester:~$
>
>
> New Port Config:
>
> root@net-ovn-db1:~# ovn-nbctl list Logical_Switch_Port opnsense1-wan
> _uuid   : 2ab1d971-3d0d-4472-b3f6-4280b083a633
> addresses   : ["fa:16:3e:61:76:50 100.64.56.252", unknown]
> dhcpv4_options  : 511c2df2-56dc-419c-9066-8a2430115144
> dhcpv6_options  : []
> dynamic_addresses   : []
> enabled : true
> external_ids: {"redacted": "true"}
> ha_chassis_group: []
> mirror_rules: []
> name: "c9d850ee-a534-4a52-8c16-b866d0a3a6d2"
> options : {mcast_flood_reports="true", requested-chassis=hv1}
> parent_name : []
> port_security   : []
> tag : []
> tag_request : []
> type: ""
> up  : true
> root@net-ovn-db1:~# ovn-nbctl list Logical_Switch_Port opnsense2-wan
> _uuid   : 3fa4640e-c60e-41d6-928d-e698843eba8a
> addresses   : ["fa:16:3e:84:d8:6c 100.64.56.253", unknown]
> dhcpv4_options  : 511c2df2-56dc-419c-9066-8a2430115144
> dhcpv6_options  : []
> dynamic_addresses   : []
> enabled : true
> external_ids: {"redacted": "true"}
> ha_chassis_group: []
> mirror_rules: []
> name: "95531103-ea2a-4040-adc4-1f2e9c24d5b9"
> options : {mcast_flood_reports="true", requested-chassis=hv2}
> parent_name : []
> port_security   : []
> tag : []
> tag_request : []
> type: ""
> up  : true
>
>
>
> Best regards,
> Justin Lamp
>
> Am 18.10.23 um 04:26 schrieb Numan Siddique:
>
> Hi,
>
> I don't think you can make your case work using the virtual ports.
> That's because virtual ports are bound on a chassis where one of the
> virtual parents sends out the virtual mac-virtual ip.
>
> However I think you can make it work by not using virtual ports.
>
> In your particular case,  you can try doing the below.
>
> $ ovn-nbctl lsp-del opnsense-wan-carp-port  # Delete the virtual port
>
> # Set an unknown address for your virtual parents.
> $ ovn-nbctl lsp-set-addresses c9d850ee-a534-4a52-8c16-b866d0a3a6d2 unknown
> $ ovn-nbctl lsp-set-addresses 95531103-ea2a-4040-adc4-1f2e9c24d5b9 unknown
>
> I tested it locally and it worked for me.
>
> Before running these commands make sure that the neutron server is
> down so that it doesn't overwrite your changes.
>
> The suggestion I gave is only for your testing to make sure that it
> works or not.  If it works, then perhaps you need to find a proper way
> to address this in neutron ml2ovn so that virtual ports are not used.
>
> Thanks
> Numan
>
>
>
> --
> Justin Lamp
> Systems Engineer
>
> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> CEO: Julian Hein, Bernd Erk, Sebastian Saemann | AG Nuernberg HRB25207
> https://www.netways.de | justin.l...@netways.de
>
> ** OSMC 2023 - November 07-09 | Nuremberg **
> ** stackconf 2024 - - Stay Tuned for 2024 | Berlin - stackconf.eu **
> ** NETWAYS Web Services - https://nws.netways.de **
> ** NETWAYS Trainings - https://netways.de/trainings **
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN: CARP not working

[Numan Siddique via discuss]

On Tue, Oct 17, 2023 at 8:06 AM Justin Lamp via discuss
 wrote:
>
> Hi,
>
> we are trying to setup an OpnSense HA Cluster that is using CARP for a 
> client. While VRRP with Keepalived or FRR work fine, we found it impossible 
> to do with CARP. Just for context it's all running in OpenStack Victoria with 
> OVN 23.09. Any help is appreciated!
>
> I think the problem behind it is that the Opnsense/FreeBSD replies to the ARP 
> request of it's VIP with it's own MAC in the header and not with it's virtual 
> 00:00:05... MAC, which it's sending in the payload. I was able to replicate 
> that behavior with ovn-trace as well. When I would use the virtual MAC the 
> virtual OVN Port would be bound and when using it's own, traffic would be 
> dropped.
>
>
> Tcpdump of OpnSense Tap Interface:
>
> 08:13:33.416505 fa:16:3e:0e:36:1b > ff:ff:ff:ff:ff:ff, ethertype ARP 
> (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 
> 100.64.56.254 tell 100.64.56.227, length 28
> 08:13:33.416593 fa:16:3e:61:76:50 > fa:16:3e:0e:36:1b, ethertype ARP 
> (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 100.64.56.254 
> is-at 00:00:5e:00:01:01, length 28
>
> OVN-Trace with payload MAC == header MAC:
>
> root@ovn-db1:~# ovn-trace --minimal 'inport == 
> "c9d850ee-a534-4a52-8c16-b866d0a3a6d2"
> && arp.op == 2
> && eth.src == 00:00:5e:00:01:01
> && arp.sha == 00:00:5e:00:01:01
>
> && eth.dst == fa:16:3e:0e:36:1b
> && arp.tha == fa:16:3e:0e:36:1b
>
> && arp.spa == 100.64.56.254
> && arp.tpa == 100.64.56.227'
> # 
> arp,reg14=0x5,vlan_tci=0x,dl_src=00:00:5e:00:01:01,dl_dst=fa:16:3e:0e:36:1b,arp_spa=100.64.56.254,arp_tpa=100.64.56.227,arp_op=2,arp_sha=00:00:5e:00:01:01,arp_tha=fa:16:3e:0e:36:1b
> output("84886d");
>
>
> OVN-Trace with payload MAC != header MAC:
>
> root@ovn-db1:~# ovn-trace --summary 'inport == 
> "c9d850ee-a534-4a52-8c16-b866d0a3a6d2"
> && arp.op == 2
> && eth.src == fa:16:3e:61:76:50
> && arp.sha == 00:00:5e:00:01:01
>
> && eth.dst == fa:16:3e:0e:36:1b
> && arp.tha == fa:16:3e:0e:36:1b
>
> && arp.spa == 100.64.56.254
> && arp.tpa == 100.64.56.227'
> # 
> arp,reg14=0x5,vlan_tci=0x,dl_src=fa:16:3e:61:76:50,dl_dst=fa:16:3e:0e:36:1b,arp_spa=100.64.56.254,arp_tpa=100.64.56.227,arp_op=2,arp_sha=00:00:5e:00:01:01,arp_tha=fa:16:3e:0e:36:1b
> ingress(dp="wan", inport="opnsense1-wan") {
> reg0[15] = check_in_port_sec();
> next;
> drop;
> };
>
> Interfaces in OVN:
>
> root@ovn-db1:~# ovn-nbctl list Logical_Switch_Port 
> c9d850ee-a534-4a52-8c16-b866d0a3a6d2
> _uuid   : 2ab1d971-3d0d-4472-b3f6-4280b083a633
> addresses   : ["00:00:5e:00:01:01", "fa:16:3e:61:76:50 100.64.56.252"]
> dhcpv4_options  : 511c2df2-56dc-419c-9066-8a2430115144
> dhcpv6_options  : []
> dynamic_addresses   : []
> enabled : true
> external_ids: {"dedacted":"true"}
> ha_chassis_group: []
> mirror_rules: []
> name: "c9d850ee-a534-4a52-8c16-b866d0a3a6d2"
> options : {mcast_flood_reports="true", 
> requested-chassis=net-openstack-hv31}
> parent_name : []
> port_security   : ["00:00:5e:00:01:01 100.64.56.254", "fa:16:3e:61:76:50 
> 100.64.56.252 100.64.56.254"]
> tag : []
> tag_request : []
> type: ""
> up  : true
> root@ovn-db1:~# ovn-nbctl list Logical_Switch_Port opnsense-wan-carp-port
> _uuid   : 975dacf8-7381-451d-99c8-8d8f1cfd9900
> addresses   : ["00:00:5e:00:01:01 100.64.56.254"]
> dhcpv4_options  : 511c2df2-56dc-419c-9066-8a2430115144
> dhcpv6_options  : []
> dynamic_addresses   : []
> enabled : true
> external_ids: {"dedacted":"true"}
> ha_chassis_group: []
> mirror_rules: []
> name: "2f9aa2a9-8ca3-4557-aadb-32f61c991d78"
> options : {mcast_flood_reports="true", requested-chassis="", 
> virtual-ip="100.64.56.254", 
> virtual-parents="c9d850ee-a534-4a52-8c16-b866d0a3a6d2,95531103-ea2a-4040-adc4-1f2e9c24d5b9"}
> parent_name : []
> port_security   : ["00:00:5e:00:01:01 100.64.56.254"]
> tag : []
> tag_request : []
> type: virtual
> up  : true
>
>
>
> The only way I can reach the .254 VIP is by setting a manual neigh entry 
> pointing to the MAC of the Opnsense. As a last resort I even tried setting 
> the addresses to unknown and disabling PortSecurity. But this only resulted 
> in ARP Replies being answered. All other traffic will be black holed as it 
> will be send to the virtual Port.
>
>
> Without PortSecurity:
>
> root@ovn-db1:~# ovn-nbctl list Logical_Switch_Port 
> c9d850ee-a534-4a52-8c16-b866d0a3a6d2
> _uuid   : 2ab1d971-3d0d-4472-b3f6-4280b083a633
> addresses   : [unknown]
> dhcpv4_options  : 511c2df2-56dc-419c-9066-8a2430115144
> dhcpv6_options  : []
> dynamic_addresses   : []
> enabled : true
> external_ids: {"dedacted":"true"}
> ha_chassis_group  

Re: [ovs-discuss] Testing for membership in set

[Numan Siddique via discuss]

On Mon, Jul 17, 2023 at 5:51 AM Gavin McKee via discuss
 wrote:
>
> Hi,
>
> Can someone help me understand how to find a uuid in a set of Ports using the 
> table below as an example?
>
> I want to check if the uuid 1191229a-6878-4dfc-b07a-47e6e2a4dcfe is in the 
> set of assigned ports (in some cases I have a large number of ports and want 
> to search for membership in a port list).
>
> [root@ovnkube-db-0 ~]# ovn-nbctl --no-leader-only find Logical_Switch 
> name=a_b461d3e2_621c_43f4_8d7c_e39c13bcba08_ls_bca4b75e_9b21_4454_98a3_e490feecae9f
>
> _uuid   : 7c28c854-a40d-4145-b6f3-7d0f0e69d5ab
> acls: []
> copp: []
> dns_records : []
> external_ids: 
> {crusoe_subnet_id="bca4b75e-9b21-4454-98a3-e490feecae9f", 
> crusoe_vpc_id="ec7f1ea4-66a2-4b9e-ac0d-79e9ec0998db", 
> customer_id="b461d3e2-621c-43f4-8d7c-e39c13bcba08"}
> forwarding_groups   : []
> load_balancer   : []
> load_balancer_group : []
> name: 
> a_b461d3e2_621c_43f4_8d7c_e39c13bcba08_ls_bca4b75e_9b21_4454_98a3_e490feecae9f
> other_config: {exclude_ips="172.27.16.0..172.27.16.4", 
> subnet="172.27.16.0/20"}
> ports   : [1191229a-6878-4dfc-b07a-47e6e2a4dcfe, 
> 2937d508-3db0-4d40-8c06-10849abcf9d9, 327e037a-b11e-4dc4-8846-08a9c262b911]
> qos_rules   : []
>
>
> Thanks
>

One way I can think of is running the below command.

# ovn-nbctl get logical_switch
a_b461d3e2_621c_43f4_8d7c_e39c13bcba08_ls_bca4b75e_9b21_4454_98a3_e490feecae9f
ports | grep 1191229a-6878-4dfc-b07a-47e6e2a4dcfe

If you don't want to use grep, then I'm not sure.

Thanks
Numan



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

Re: [ovs-discuss] [ovs-dev] connect VM on OVN/OVS and BMS on L2

[Numan Siddique via discuss]

On Fri, May 19, 2023 at 12:09 AM Tony Liu  wrote:
>
> Hi Numan,
>
> Provider VLAN networks is able to connect VM and BMS on L2.
> I am going to push this topic further.
>
> Provider VLAN network is different from regular virtual network.
> It seems that I can't create a logical router to connect a provider VLAN
> and regular VN. The way I am using provider VLAN is as external network
> whose GW is on physical router. Also in a multi-tenancy cloud, provider
> VLAN network can't be created by user. I wonder if we can build a regular
> VN to connect VM and BMS?
>
> OVN is using Geneve which is not commonly supported by networking devices.
> VxLAN doesn't seem to be an option cause OVN needs Geneve to carry metadata.
> I see some vxlan supports in OVN but not sure how it works or for which case 
> exactly.
>
> Tungsten Fabric supports this because it uses vxlan as the overlay. To 
> connect VM
> to BMS, vrouter will create a vxlan from compute node to BMS VTEP (typically 
> the ToR).
> That's how BMS is brought into overlay by vxlan, and will be treated just 
> like a VM.
> With the EVPN support in control plane, routing info is populated between 
> vrouter
> and VTEPand. And with some orchestration to networking devices, the networking
> support to BMS is seamless. One concern is that no SG for BMS, which can be
> actually supported by networking device.
>
> Can the similar supported by OVN or any other overlay solution supported by 
> OVN
> to connect BMS?
>

I think I should have asked this question earlier.  What is BMS ?   I
presumed it to be Bare metal server
and thought that you want to communicate a bare metal server on your
L2 network and a VM in OVN logical switch with localnet port.

OVN supports ovn-controller-vtep to connect OVN to a vtep switch.  I
don't have much experience there.

Maybe you can check it out ?
https://www.ovn.org/support/dist-docs/ovn-controller-vtep.8.html

Adding @Vladislav Odintsov  to the thread who has been using
ovn-controller-vtep to connect to a vtep switch and if he has any
comments.

Thanks
Numan

>
> Thanks!
> Tony
> 
> From: Numan Siddique 
> Sent: May 18, 2023 11:18 AM
> To: Tony Liu
> Cc: ovs-dev; ovs-discuss
> Subject: Re: [ovs-discuss] [ovs-dev] connect VM on OVN/OVS and BMS on L2
>
>
>
> On Thu, May 18, 2023, 1:15 PM Tony Liu via discuss 
> mailto:ovs-discuss@openvswitch.org>> wrote:
> Hi Numan,
>
> Good to see you pick it up, no need to bother OpenStack alias.
> My ultimate target is to support VM and BMS L2 connectivity with OpenStack.
> I used to make that work with other virtual networking stack, not sure how 
> much
> it's supported by OVN/OVS. Any comments in that context
>
>
> It is definitely supported with open stack.
>
> I think you need to create a provider vlan neutron network.
>
> Thanks
> Numan
>
>
> Thanks!
> Tony
> 
> From: Numan Siddique mailto:num...@ovn.org>>
> Sent: May 18, 2023 09:51 AM
> To: Tony Liu
> Cc: ovs-discuss; ovs-dev
> Subject: Re: [ovs-dev] connect VM on OVN/OVS and BMS on L2
>
> On Thu, May 18, 2023 at 12:19 PM Tony Liu 
> mailto:tonyliu0...@hotmail.com>> wrote:
> >
> > Hi,
> >
> > Could you anyone share experiences or point to some reference about how
> > to connect VM on OVN/OVS and BMS on L2? Or say, how can I connect BMS
> > to a logical switch on OVN/OVS?
>
> For this you need to create a localnet port in the logical switch.
>
> Something like this:
>
> ovn-nbctl ls-add public
> # localnet port
> ovn-nbctl lsp-add public ln-public
> ovn-nbctl lsp-set-type ln-public localnet
> ovn-nbctl lsp-set-addresses ln-public unknown
> ovn-nbctl lsp-set-options ln-public network_name=public
>
> # create a few VM ports
>
> ovn-nbctl lsp-add public pub-port1
> ovn-nbctl lsp-set-addresses pub-port1 "50:54:00:00:00:03
> 172.168.0.100"  (assuming your L2 network is 
> 172.168.0.0/24<http://172.168.0.0/24>)
>
> ovn-nbctl lsp-add public pub-port2
> ovn-nbctl lsp-set-addresses pub-port2 "50:54:00:00:00:04 172.168.0.101"
>
> # On the compute node(s) where you create the VMs
>
> ovs-vsctl set open . external_ids:ovn-bridge-mappings="public:br-ex"
>
> ovs-vsctl add-br br-ex
> ovs-vsctl add-port eth1  # assuming eth1 is your physical interface
> connecting to your L2 switch
>
> After this connectivity from your VM (bound to logical port pub-port1)
> should be able to communicate to your BMS.
>
>
> Thanks
> Numan
>
> >
> >
> > Thanks!
> > Tony
> > __

Re: [ovs-discuss] [ovs-dev] connect VM on OVN/OVS and BMS on L2

[Numan Siddique via discuss]

On Thu, May 18, 2023, 1:15 PM Tony Liu via discuss <
ovs-discuss@openvswitch.org> wrote:

> Hi Numan,
>
> Good to see you pick it up, no need to bother OpenStack alias.
> My ultimate target is to support VM and BMS L2 connectivity with OpenStack.
> I used to make that work with other virtual networking stack, not sure how
> much
> it's supported by OVN/OVS. Any comments in that context
>


It is definitely supported with open stack.

I think you need to create a provider vlan neutron network.

Thanks
Numan


> Thanks!
> Tony
> ____
> From: Numan Siddique 
> Sent: May 18, 2023 09:51 AM
> To: Tony Liu
> Cc: ovs-discuss; ovs-dev
> Subject: Re: [ovs-dev] connect VM on OVN/OVS and BMS on L2
>
> On Thu, May 18, 2023 at 12:19 PM Tony Liu  wrote:
> >
> > Hi,
> >
> > Could you anyone share experiences or point to some reference about how
> > to connect VM on OVN/OVS and BMS on L2? Or say, how can I connect BMS
> > to a logical switch on OVN/OVS?
>
> For this you need to create a localnet port in the logical switch.
>
> Something like this:
>
> ovn-nbctl ls-add public
> # localnet port
> ovn-nbctl lsp-add public ln-public
> ovn-nbctl lsp-set-type ln-public localnet
> ovn-nbctl lsp-set-addresses ln-public unknown
> ovn-nbctl lsp-set-options ln-public network_name=public
>
> # create a few VM ports
>
> ovn-nbctl lsp-add public pub-port1
> ovn-nbctl lsp-set-addresses pub-port1 "50:54:00:00:00:03
> 172.168.0.100"  (assuming your L2 network is 172.168.0.0/24)
>
> ovn-nbctl lsp-add public pub-port2
> ovn-nbctl lsp-set-addresses pub-port2 "50:54:00:00:00:04 172.168.0.101"
>
> # On the compute node(s) where you create the VMs
>
> ovs-vsctl set open . external_ids:ovn-bridge-mappings="public:br-ex"
>
> ovs-vsctl add-br br-ex
> ovs-vsctl add-port eth1  # assuming eth1 is your physical interface
> connecting to your L2 switch
>
> After this connectivity from your VM (bound to logical port pub-port1)
> should be able to communicate to your BMS.
>
>
> Thanks
> Numan
>
> >
> >
> > Thanks!
> > Tony
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] connect VM on OVN/OVS and BMS on L2

[Numan Siddique via discuss]

On Thu, May 18, 2023 at 12:19 PM Tony Liu  wrote:
>
> Hi,
>
> Could you anyone share experiences or point to some reference about how
> to connect VM on OVN/OVS and BMS on L2? Or say, how can I connect BMS
> to a logical switch on OVN/OVS?

For this you need to create a localnet port in the logical switch.

Something like this:

ovn-nbctl ls-add public
# localnet port
ovn-nbctl lsp-add public ln-public
ovn-nbctl lsp-set-type ln-public localnet
ovn-nbctl lsp-set-addresses ln-public unknown
ovn-nbctl lsp-set-options ln-public network_name=public

# create a few VM ports

ovn-nbctl lsp-add public pub-port1
ovn-nbctl lsp-set-addresses pub-port1 "50:54:00:00:00:03
172.168.0.100"  (assuming your L2 network is 172.168.0.0/24)

ovn-nbctl lsp-add public pub-port2
ovn-nbctl lsp-set-addresses pub-port2 "50:54:00:00:00:04 172.168.0.101"

# On the compute node(s) where you create the VMs

ovs-vsctl set open . external_ids:ovn-bridge-mappings="public:br-ex"

ovs-vsctl add-br br-ex
ovs-vsctl add-port eth1  # assuming eth1 is your physical interface
connecting to your L2 switch

After this connectivity from your VM (bound to logical port pub-port1)
should be able to communicate to your BMS.


Thanks
Numan

>
>
> Thanks!
> Tony
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovn-northd: Trying to delete a key that doesn't exist in the set.

[Numan Siddique via discuss]

On Wed, May 10, 2023 at 7:24 AM Ilya Maximets via discuss
 wrote:
>
> On 5/10/23 05:33, 张祖建 wrote:
> >
> > Attached is the ovn-northd log file.
> >
> > Numan Siddique mailto:num...@ovn.org>> 于2023年5月10日周三 
> > 08:03写道：
> >
> > On Tue, May 9, 2023 at 1:29 PM Ilya Maximets via discuss
> > mailto:ovs-discuss@openvswitch.org>> 
> > wrote:
> > >
> > > On 5/5/23 10:22, 张祖建 via discuss wrote:
> > > > Hi, all:
> > > >
> > > > I'm using OVN ACL with address set. Sometimes an ACL rule does not 
> > work as expected after updating address set addresses, and ovn-northd 
> > reports the following warning:
> > > >
> > > > 2023-05-05T08:00:07.298Z|00217|ovsdb_idl|WARN|Trying to delete a 
> > key that doesn't exist in the set.
> > > >
> > > > After some investigation, I found the reason is that ovn-northd 
> > tries to delete an address 0.0.0.0/4 <http://0.0.0.0/4> <http://0.0.0.0/4 
> > <http://0.0.0.0/4>> from the addresses column while the existing addresses 
> > are 10.16.0.47/4 <http://10.16.0.47/4> <http://10.16.0.47/4 
> > <http://10.16.0.47/4>> and 10.16.3.48/32 <http://10.16.3.48/32> 
> > <http://10.16.3.48/32 <http://10.16.3.48/32>>.
> > > >
> > > > I added some debug logging and found that there are two functions 
> > responsible for updating ovn sb address_set,  update_sb_addr_set() and 
> > sync_addr_set(). In update_sb_addr_set(), ovn-northd formats 10.16.0.47/4 
> > <http://10.16.0.47/4> <http://10.16.0.47/4 <http://10.16.0.47/4>> to 
> > 0.0.0.0/4 <http://0.0.0.0/4> <http://0.0.0.0/4 <http://0.0.0.0/4>> and 
> > writes the later to ovn sb. While in sync_addr_set(), ovn-northd writes 
> > 10.16.0.47/4 <http://10.16.0.47/4> <http://10.16.0.47/4 
> > <http://10.16.0.47/4>> to sb directly.
> > > >
> > > > I believe this is a bug.
> > > >
> > > > OVN version: v22.12
> > >
> > > CC: Numan
> > >
> > > Thanks for the report!  This indeed looks like a bug in the
> > > address set incremental processing in northd.
> > >
> > > If address set doesn't already exist, sync_addr_set() function
> > > just copies to Sb without any processing on the addresses, but
> > > during the update all addresses are going through expression
> > > parsing and formatting that is getting rid of bits that are not
> > > part of the mask.  And that creates a difference and inability
> > > to remove the address from Sb as a result.
> > >
> > > Best regards, Ilya Maximets.
> >
> > Thanks for the report.
> >
> > Is it possible to enable jsonrpc dbg in ovn-northd and share the logs
> > when you see this issue ?
> > (ovn-appctl -t ovn-northd vlog/set jsonrpc:dbg)
> >
> > Or if you can share a simple ovn-nbctl script to reproduce this issue
> > and/or attach the OVN Northbound db that would be great.
>
> FWIW, the simple reproducer:
>
> [tutorial]$ as_uuid=$(ovn-nbctl --wait=sb create address-set name=as1 
> addresses=10.16.0.47/4,10.16.3.48/32)
> [tutorial]$ ovn-nbctl --wait=sb remove address_set $as_uuid addresses 
> 10.16.0.47/4
> [tutorial]$ cat sandbox/ovn-northd.log | grep WARN
> 2023-05-10T11:22:38.998Z|00012|ovsdb_idl|WARN|Trying to delete a key that 
> doesn't exist in the set.

Thanks for the logs and thanks Ilya for the reproducer.

I've raised a bugzilla to track it here -
https://bugzilla.redhat.com/show_bug.cgi?id=2196885

I'll see if I can fix this and put a patch for review.

Thanks
Numan

>
>
> >
> > Thanks
> > Numan
> >
> >
> >
> > > ___
> > > discuss mailing list
> > > disc...@openvswitch.org <mailto:disc...@openvswitch.org>
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss 
> > <https://mail.openvswitch.org/mailman/listinfo/ovs-discuss>
> >
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovn-northd: Trying to delete a key that doesn't exist in the set.

[Numan Siddique via discuss]

On Tue, May 9, 2023 at 1:29 PM Ilya Maximets via discuss
 wrote:
>
> On 5/5/23 10:22, 张祖建 via discuss wrote:
> > Hi, all:
> >
> > I'm using OVN ACL with address set. Sometimes an ACL rule does not work as 
> > expected after updating address set addresses, and ovn-northd reports the 
> > following warning:
> >
> > 2023-05-05T08:00:07.298Z|00217|ovsdb_idl|WARN|Trying to delete a key that 
> > doesn't exist in the set.
> >
> > After some investigation, I found the reason is that ovn-northd tries to 
> > delete an address 0.0.0.0/4  from the addresses column 
> > while the existing addresses are 10.16.0.47/4  and 
> > 10.16.3.48/32 .
> >
> > I added some debug logging and found that there are two functions 
> > responsible for updating ovn sb address_set,  update_sb_addr_set() and 
> > sync_addr_set(). In update_sb_addr_set(), ovn-northd formats 10.16.0.47/4 
> >  to 0.0.0.0/4  and writes the later 
> > to ovn sb. While in sync_addr_set(), ovn-northd writes 10.16.0.47/4 
> >  to sb directly.
> >
> > I believe this is a bug.
> >
> > OVN version: v22.12
>
> CC: Numan
>
> Thanks for the report!  This indeed looks like a bug in the
> address set incremental processing in northd.
>
> If address set doesn't already exist, sync_addr_set() function
> just copies to Sb without any processing on the addresses, but
> during the update all addresses are going through expression
> parsing and formatting that is getting rid of bits that are not
> part of the mask.  And that creates a difference and inability
> to remove the address from Sb as a result.
>
> Best regards, Ilya Maximets.

Thanks for the report.

Is it possible to enable jsonrpc dbg in ovn-northd and share the logs
when you see this issue ?
(ovn-appctl -t ovn-northd vlog/set jsonrpc:dbg)

Or if you can share a simple ovn-nbctl script to reproduce this issue
and/or attach the OVN Northbound db that would be great.

Thanks
Numan



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

Re: [ovs-discuss] OVN/OVS tunnel to public cloud provider

[Numan Siddique via discuss]

On Tue, Feb 14, 2023 at 6:40 PM Gavin McKee via discuss
 wrote:
>
> Hi Numan,
>
> I'd be happy to start with static routes , as long as I can get the 
> connectivity in place i.e. be able to connect a VM on a logical switch to a 
> VM in a public cloud via IPSEC tunnel.

so you're trying to connect an OVN deployment on one end and a public
cloud on the other.  Looks to me you may need to establish an IPSEC
tunnel yourself.  One end of the tunnel should be
your gateway node in OVN deployment and other end your public cloud.

For North/South gateway traffic to work with OVN,  you need to
configure ovn-bridge-mappings on the gateway node.  OVN will create a
patch port from br-int to the provider ovs bridge (lets say br-ex).
And it is expected that br-ex would be attached with a physical nic
which would provide connectivity to the external.

Seems to me you need to establish the IPSEC tunnel in br-ex as this is
out of OVN's scope.

Thanks
Numan


>
> Gav
>
> On Tue, Feb 14, 2023 at 3:28 PM Numan Siddique  wrote:
>>
>> Looks like this would require BGP to exchange the routes ?
>>
>> I'm not sure. I may be wrong. Adding @Daniel Alvarez Sanchez if he
>> has any comments as he worked on supporting BGP in Openstack with OVN.
>>
>> Thanks
>> Numan
>>
>>
>> On Tue, Feb 14, 2023 at 1:50 PM Gavin McKee via discuss
>>  wrote:
>> >
>> > Satish,
>> >
>> > We are using the Mellanox Connect X6 card / possibly we can use bluefield2 
>> > card to do IPSEC hardware offload . So somehow we could build a tunnel to 
>> > a server with StrongSwan IPSEC . The key thing is to tie this IPSEC 
>> > interface into the OVN/OVS setup and somehow associate it with a 
>> > customer's virtual router.
>> >
>> > Am I even thinking off this the correct way?
>> >
>> > Gav
>> >
>> >
>> > On Tue, Feb 14, 2023 at 7:15 AM Satish Patel  wrote:
>> >>
>> >> Seems like OVN does support IPsec tunnel based on doc but may need to 
>> >> figure out how to integrate with your use case [1]
>> >>
>> >> [1] https://docs.ovn.org/en/latest/tutorials/ovn-ipsec.html
>> >>
>> >> On Tue, Feb 14, 2023 at 8:20 AM Gavin McKee via discuss 
>> >>  wrote:
>> >>>
>> >>> Hi ,
>> >>>
>> >>> Is it possible to connect an IPSEC tunnel from a Public cloud provider 
>> >>> such as Azure, AWS / GCP to an OVN logical router ?
>> >>>
>> >>> I need to be able to route between a subnet in Azure / GCP and a subnet 
>> >>> in OVN?
>> >>>
>> >>> Has anyone been able to achieve this , and if so can you provide an 
>> >>> example configuration ?
>> >>>
>> >>> Gav
>> >>>
>> >>>
>> >>> Disclaimer
>> >>>
>> >>> The information contained in this communication from the sender is 
>> >>> confidential. It is intended solely for use by the recipient and others 
>> >>> authorized to receive it. If you are not the recipient, you are hereby 
>> >>> notified that any disclosure, copying, distribution or taking action in 
>> >>> relation of the contents of this information is strictly prohibited and 
>> >>> may be unlawful.
>> >>>
>> >>> ___
>> >>> discuss mailing list
>> >>> disc...@openvswitch.org
>> >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>> >
>> >
>> >
>> > Disclaimer
>> >
>> > The information contained in this communication from the sender is 
>> > confidential. It is intended solely for use by the recipient and others 
>> > authorized to receive it. If you are not the recipient, you are hereby 
>> > notified that any disclosure, copying, distribution or taking action in 
>> > relation of the contents of this information is strictly prohibited and 
>> > may be unlawful.
>> >
>> > ___
>> > discuss mailing list
>> > disc...@openvswitch.org
>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
>
> Disclaimer
>
> The information contained in this communication from the sender is 
> confidential. It is intended solely for use by the recipient and others 
> authorized to receive it. If you are not the recipient, you are hereby 
> notified that any disclosure, copying, distribution or taking action in 
> relation of the contents of this information is strictly prohibited and may 
> be unlawful.
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN/OVS tunnel to public cloud provider

[Numan Siddique via discuss]

Looks like this would require BGP to exchange the routes ?

I'm not sure.  I may be wrong.  Adding @Daniel Alvarez Sanchez  if he
has any comments as he worked on supporting BGP in Openstack with OVN.

Thanks
Numan


On Tue, Feb 14, 2023 at 1:50 PM Gavin McKee via discuss
 wrote:
>
> Satish,
>
> We are using the Mellanox Connect X6 card / possibly we can use bluefield2 
> card to do IPSEC hardware offload .  So somehow we could build a tunnel to a 
> server with StrongSwan IPSEC .  The key thing is to tie this IPSEC interface 
> into the OVN/OVS setup and somehow associate it with a customer's virtual 
> router.
>
> Am I even thinking off this the correct way?
>
> Gav
>
>
> On Tue, Feb 14, 2023 at 7:15 AM Satish Patel  wrote:
>>
>> Seems like OVN does support IPsec tunnel based on doc but may need to figure 
>> out how to integrate with your use case [1]
>>
>> [1] https://docs.ovn.org/en/latest/tutorials/ovn-ipsec.html
>>
>> On Tue, Feb 14, 2023 at 8:20 AM Gavin McKee via discuss 
>>  wrote:
>>>
>>> Hi ,
>>>
>>> Is it possible to connect an IPSEC tunnel from a Public cloud provider such 
>>> as Azure, AWS / GCP to an OVN logical router ?
>>>
>>> I need to be able to route between a subnet in Azure / GCP and a subnet in 
>>> OVN?
>>>
>>> Has anyone been able to achieve this , and if so can you provide an example 
>>> configuration ?
>>>
>>> Gav
>>>
>>>
>>> Disclaimer
>>>
>>> The information contained in this communication from the sender is 
>>> confidential. It is intended solely for use by the recipient and others 
>>> authorized to receive it. If you are not the recipient, you are hereby 
>>> notified that any disclosure, copying, distribution or taking action in 
>>> relation of the contents of this information is strictly prohibited and may 
>>> be unlawful.
>>>
>>> ___
>>> discuss mailing list
>>> disc...@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
>
> Disclaimer
>
> The information contained in this communication from the sender is 
> confidential. It is intended solely for use by the recipient and others 
> authorized to receive it. If you are not the recipient, you are hereby 
> notified that any disclosure, copying, distribution or taking action in 
> relation of the contents of this information is strictly prohibited and may 
> be unlawful.
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN DHCP IP Assignment

[Numan Siddique via discuss]

On Tue, Jan 17, 2023 at 3:10 AM Moiz Ibrahim Randhikpurwala (IT) via
discuss  wrote:
>
> Hi
>
>
>
> We are trying to use OVN DHCP option for a network. The IP assigned by the 
> DHCP is an IP which is already assigned to a VM.
>
>
>
> Does the OVN DHCP option check for the IP or ping the IP before assigning to 
> another VM? Are there any option to enable the check?

Hi,

No. OVN doesn't do that.  Please check this out.  It has some details
on how OVN DHCP works -
https://numans.blog/2016/08/09/native-dhcp-support-in-ovn/

Thanks
Numan

>
>
>
> Moiz R
>
> DISCLAIMER: This e-mail message including any of its attachments is intended 
> solely for the addressee(s) and may contain privileged information. If you 
> are not the addressee or you have received this email message in error, 
> please notify the sender who will remove your details from its database. You 
> are not authorized to read, copy, disseminate, distribute or use this e-mail 
> message or any attachment to it in any manner and must delete the email and 
> destroy any hard copies of it. This e-mail message does not contain financial 
> instructions or commitments of any kind. Any views expressed in this message 
> are those of the individual sender and do not necessarily reflect the views 
> of Emirates NBD PJSC, or any other related subsidiaries, entities or persons.
>
> Emirates NBD Bank (P.J.S.C.) is licensed by the Central Bank of the UAE.
> .بنك الإمارات دبي الوطني ش.م.ع. هو بنك مرخّص من قبل مصرف الإمارات العربية 
> المتحدة المركزي DISCLAIMER: This e-mail message including any of its 
> attachments is intended solely for the addressee(s) and may contain 
> privileged information. If you are not the addressee or you have received 
> this email message in error, please notify the sender who will remove your 
> details from its database. You are not authorized to read, copy, disseminate, 
> distribute or use this e-mail message or any attachment to it in any manner 
> and must delete the email and destroy any hard copies of it. This e-mail 
> message does not contain financial instructions or commitments of any kind. 
> Any views expressed in this message are those of the individual sender and do 
> not necessarily reflect the views of Emirates NBD PJSC, or any other related 
> subsidiaries, entities or persons.
>
> Emirates NBD Bank (P.J.S.C.) is licensed by the Central Bank of the UAE.
> .بنك الإمارات دبي الوطني ش.م.ع. هو بنك مرخّص من قبل مصرف الإمارات العربية 
> المتحدة المركزي
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Distributed router and IPv6 support

[Numan Siddique via discuss]

On Thu, Dec 1, 2022 at 1:13 PM Gavin McKee via discuss
 wrote:
>
> Numan,
>
> I have a similar problem to Roberto, (not exact but I believe he will run 
> into this issue also) in which I need a G-ARP to generate a type 2 mac-ip 
> route in EVPN.  When I add the NAT with the binding to the logical switch 
> port and external MAC I see a G-ARP immediately , the switch learns this 
> G-ARP and generates the correct ip route.  The problem is garp is NOT sent 
> periodically so if the ARP cache times out you always need traffic from the 
> overlay to keep this alive.  Should OVN be sending a periodic garp and if so 
> on what interval?

I think garps are sent initially for a VIF with a burst of 5 or so packets.
If we want to send periodic garps, we need to enhance the
ovn-controller.  Perhaps we can add an option to say if we want
continuous garps or an initial burst.

Please feel free to propose a patch if you think you can tackle this.
Otherwise can you please create a github issue so that it's not out of
radar.

Thanks
Numan

>
> I'm running Ovn 22.03.0
>
> root@usc01a-lab-ovn04:/home/gmckee# ovn-nbctl list nat
> _uuid   : 59489984-ac1e-4f4b-8dc8-cace49a64360
> allowed_ext_ips : []
> exempted_ext_ips: []
> external_ids: {}
> external_ip : "216.147.118.8"
> external_mac: "0a:99:00:32:15:07"
> external_port_range : ""
> logical_ip  : "10.200.1.12"
> logical_port: c1-sw1-p2
> options : {stateless="false"}
> type: dnat_and_snat
>
>
> root@usc01a-lab-ovn04:/home/gmckee# ovn-nbctl list Logical_Switch_Port 
> localswitch-lr0
> _uuid   : 010984e7-102c-4917-a6c9-59f6d554ffea
> addresses   : [router]
> dhcpv4_options  : []
> dhcpv6_options  : []
> dynamic_addresses   : []
> enabled : []
> external_ids: {}
> ha_chassis_group: []
> name: localswitch-lr0
> options : {nat-addresses=router, router-port=c1-lr0-localswitch}
> parent_name : []
> port_security   : []
> tag : []
> tag_request : []
> type: router
> up  : true
>
> On Thu, 1 Dec 2022 at 09:18, Numan Siddique via discuss 
>  wrote:
>>
>> On Thu, Dec 1, 2022 at 10:15 AM Roberto Bartzen Acosta via discuss
>>  wrote:
>> >
>> > Hey folks,
>> >
>> > I would like some help to understand how DVR works in ovn/ovs. Currently, 
>> > DVR support for FIP addresses works perfectly. However, I would like to 
>> > understand if it is possible to extend this behavior to IPv6 addresses. 
>> > When I talk about IPv6 addresses, I'm referring to the GUA addresses that 
>> > are allocated to VMs (e.g., considering an openstack deployment).
>> >
>> > I understand that there are other requirements for GUA addresses to be 
>> > routed to external networks by OVN (here comes the work of the 
>> > neutron-dynamic-routing project + FRR on hypervisors/openvswitch). For DVR 
>> > to be enabled properly, the provider networks must be stretched over the 
>> > Underlay Network and each Compute Node would have the bridge for external 
>> > traffic. In an L3 Leaf-Spine Underlay network one option for this 
>> > requirement to be reached is for the Underlay Network be able to stretch 
>> > an L2 domain(VLAN) via VXLAN as dataplane and BGP EVPN as Control Plane. 
>> > In this solution, the Leaf switches would need to work as HW VTEP Gateway 
>> > to initiate and terminate the VXLANs tunnels and use BGP EVPN to learn and 
>> > advertise the MAC Addresses from the Compute Node’s provider network.
>> >
>> > The common reference architecture is detailed in [picture 1] and the 
>> > design for the DVR+FRR solution (IPv4/IPv6) is detailed in [picture 2].
>> >
>> > What's the problem? well, inbound traffic to a GUA address goes through 
>> > the chassis where the router's external port resides.
>> >
>> >
>> > Looking at the DVR implementation for IPv4, I see that the solution is 
>> > heavily based on the idea of NAT. From initial support in [1], some fixes 
>> > in [2] and [3], and scalability improvements in [4].
>> >
>> >
>> > With some debugs in the openflow pipeline, I see the entries for snat and 
>> > dnat (FIP = 200.201.0.226) with reference to is_chassis_resident (with 
>> > cr-lrp).
>> >
>> > _uuid   : d37d412b-28ed-4d55-8f97-533571ffb3c1
>> > a

Re: [ovs-discuss] Distributed router and IPv6 support

[Numan Siddique via discuss]

On Thu, Dec 1, 2022 at 10:15 AM Roberto Bartzen Acosta via discuss
 wrote:
>
> Hey folks,
>
> I would like some help to understand how DVR works in ovn/ovs. Currently, DVR 
> support for FIP addresses works perfectly. However, I would like to 
> understand if it is possible to extend this behavior to IPv6 addresses. When 
> I talk about IPv6 addresses, I'm referring to the GUA addresses that are 
> allocated to VMs (e.g., considering an openstack deployment).
>
> I understand that there are other requirements for GUA addresses to be routed 
> to external networks by OVN (here comes the work of the 
> neutron-dynamic-routing project + FRR on hypervisors/openvswitch). For DVR to 
> be enabled properly, the provider networks must be stretched over the 
> Underlay Network and each Compute Node would have the bridge for external 
> traffic. In an L3 Leaf-Spine Underlay network one option for this requirement 
> to be reached is for the Underlay Network be able to stretch an L2 
> domain(VLAN) via VXLAN as dataplane and BGP EVPN as Control Plane. In this 
> solution, the Leaf switches would need to work as HW VTEP Gateway to initiate 
> and terminate the VXLANs tunnels and use BGP EVPN to learn and advertise the 
> MAC Addresses from the Compute Node’s provider network.
>
> The common reference architecture is detailed in [picture 1] and the design 
> for the DVR+FRR solution (IPv4/IPv6) is detailed in [picture 2].
>
> What's the problem? well, inbound traffic to a GUA address goes through the 
> chassis where the router's external port resides.
>
>
> Looking at the DVR implementation for IPv4, I see that the solution is 
> heavily based on the idea of NAT. From initial support in [1], some fixes in 
> [2] and [3], and scalability improvements in [4].
>
>
> With some debugs in the openflow pipeline, I see the entries for snat and 
> dnat (FIP = 200.201.0.226) with reference to is_chassis_resident (with 
> cr-lrp).
>
> _uuid   : d37d412b-28ed-4d55-8f97-533571ffb3c1
> actions : "ct_dnat_in_czone(192.168.0.120);"
> controller_meter: []
> external_ids: {source="northd.c:12693", stage-hint="5e41244f", 
> stage-name=lr_in_dnat}
> logical_datapath: c3ea6752-5b60-40ec-9734-dcfecbb59f68
> logical_dp_group: []
> match   : "ip && ip4.dst == 200.201.0.226 && inport == 
> \"lrp-bcf42b8c-5ca5-44d1-8065-6f36892a1473\" && 
> is_chassis_resident(\"cr-lrp-bcf42b8c-5ca5-44d1-8065-6f36892a1473\")"
> pipeline: ingress
> priority: 100
> table_id: 6
> tags: {}
> hash: 0
>
>
> Does distributed router support for IPv6 need some kind of NAT rule to work? 
> And about NAT, I saw that there is a test case on system-ovn.at [5] that 
> validates NAT operation for a distributed router with IPv6 N/S traffic, is 
> that right? maybe for local addresses it might make some sense, but for N/S 
> traffic - GUA address (does this test make sense?).

In the case of DVR for FIPS, when a NAT entry is added for the FIP in
the logical router, CMS has to set external_mac and logical_port
fields.
When these are set, ovn-controller claiming the VM of the FIP will
reply for the ARP requests for the FIP.  The same for IPv6 FIPs.  Also
the ovn-controller sends periodic GARPs.

I think for the use case you mentioned,  same has to happen.  i.e For
a Neighbor Solicitation request for the GUA of the VM,  the reply
should be sent from the same compute node hosting the VM.

Can you please try adding a NAT entry in the logical router like below ?

# ovn-nbctl --help | grep lr-nat-ad
  lr-nat-add ROUTER TYPE EXTERNAL_IP LOGICAL_IP [LOGICAL_PORT EXTERNAL_MAC]

# ovn-nbctl lr-nat-add  dnat_and_snat 

I've not tried this.  If you notice the EXTERNAL_IP and LOGICAL_IP are
the same (ie VM GUA).  If you add an entry like this,
ovn should add logical flows to respond to IPv6 NS requests for the VM GUA.

If this doesn't work, then we need to think of a solution in OVN.

Thanks
Numan

>
> However, it is clear that when the external port of the router is in another 
> chassis, the incoming traffic passes through the external port of the router 
> [tcpdump 1]. The traffic is redirected to the chassis resident via geneve 
> [dpcl 1] and goes through the resident chassis for the external destination 
> GUA directly via vxlan[tcpdump 2] without going back through geneve to the 
> router.
>
>
> Any ideas about how to program the ovn so that the chassis with the GUA 
> address can receive and send traffic directly? (without redirection to the 
> centralized router).
>
> Regards,
> Roberto
>
> [picture 1] -  
> https://drive.google.com/file/d/1oaGmKbFGHqMwBxKVxsT4I-7rFt2pXSJW/view?usp=sharing
> [picture 2] -  
> https://drive.google.com/file/d/1E-MRe9WJubPz5ZP836bNPFPRMuPCt4_s/view?usp=sharing
>
>
> [1] 
> https://github.com/ovn-org/ovn/commit/ceacd9d49316d16b9273151bc1ecae9a2b2beeb8
> [2] 
> https://github.com/ovn-org/ovn/commit/551e3d989557bd2249d5bbe0978b4

Re: [ovs-discuss] OVN-k8s VLAN support

[Numan Siddique via discuss]

On Sat, Nov 26, 2022 at 7:24 PM kevin parrikar via discuss <
ovs-discuss@openvswitch.org> wrote:

> Hello,
> Can you please tell me if there is a plan to support VLAN aware interfaces
> for pods or is there a way to make VxLAN terminate on underlay devices with
> EvPN Type 2 enabled.
> Similar to https://github.com/kubeovn/kube-ovn/blob/master/docs/vlan.md
> [image: image.png]
>
>  so that integration with existing infrastructure would be easier without
> a VxLAN gateway.
>

Hi,
OVN supports VLAN tagging for the logical ports.  I think you should direct
your question to the ovn-kubernetes community here -
https://github.com/ovn-org/ovn-kubernetes/issues


Thanks
Numan

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

Re: [ovs-discuss] OVN is crashing with 'ovn-ctl start_northd'

[Numan Siddique via discuss]

On Mon, Nov 14, 2022 at 1:00 AM Spoorthi K via discuss
 wrote:
>
> Thanks for the reply Numan!
>
> When I use the OVS submodule for OVN compilation, I don't have any issues.
> Also when I compile OVS with DPDK libraries configured as "shared", I don't 
> see any issues.
>
> A question here: If I don't use DPDK with OVS for compiling and installing 
> OVN, can I still use OVS with DPDK installed with this new OVN?

Yes.  You definitely can.

Thanks
Numan


>
> Regards,
> Spoorthi
>
>
> On Mon, Nov 14, 2022 at 1:26 AM Numan Siddique  wrote:
>>
>> On Sat, Nov 12, 2022 at 9:57 PM Spoorthi K via discuss
>>  wrote:
>> >
>> > Hi,
>> >
>> > I have installed OVN from source and tried to start northd and ended up 
>> > with the following crash. Couldn't someone please point out what's going 
>> > wrong here?
>> >
>> > [root@dell-r640-033 ovn]# ovn-ctl start_northd
>> > Starting ovsdb-nb  [  OK  ]
>> > EAL: RTE_MBUF_DYNFIELD tailq is already registered
>> > PANIC in tailqinitfn_mbuf_dynfield_tailq():
>> > Cannot initialize tailq: RTE_MBUF_DYNFIELD
>> > 6: [ovn-nbctl() [0x42129e]]
>> > 5: [/lib64/libc.so.6(__libc_start_main+0x78) [0x7f8f5f9a6d18]]
>> > 4: [ovn-nbctl() [0x6252cd]]
>> > 3: [ovn-nbctl() [0x418c01]]
>> > 2: [ovn-nbctl(__rte_panic+0xba) [0x419184]]
>> > 1: [ovn-nbctl(rte_dump_stack+0x1b) [0x60f1eb]]
>> > /usr/local/share/ovn/scripts/ovn-ctl: line 154: 582562 Aborted 
>> > (core dumped) $(echo ovn-${db}ctl | tr _ -) --no-leader-only 
>> > --db="unix:$sock" init
>> > Starting ovsdb-sb  [  OK  ]
>> > EAL: RTE_MBUF_DYNFIELD tailq is already registered
>> > PANIC in tailqinitfn_mbuf_dynfield_tailq():
>> > Cannot initialize tailq: RTE_MBUF_DYNFIELD
>> > 6: [ovn-sbctl() [0x4212de]]
>> > 5: [/lib64/libc.so.6(__libc_start_main+0x78) [0x7f0e383b2d18]]
>> > 4: [ovn-sbctl() [0x5f5e8d]]
>> > 3: [ovn-sbctl() [0x418c06]]
>> > 2: [ovn-sbctl(__rte_panic+0xba) [0x419189]]
>> > 1: [ovn-sbctl(rte_dump_stack+0x1b) [0x5dfdab]]
>> > /usr/local/share/ovn/scripts/ovn-ctl: line 154: 582588 Aborted 
>> > (core dumped) $(echo ovn-${db}ctl | tr _ -) --no-leader-only 
>> > --db="unix:$sock" init
>> > Starting ovn-northd EAL: RTE_MBUF_DYNFIELD tailq is already registered
>> > PANIC in tailqinitfn_mbuf_dynfield_tailq():
>> > Cannot initialize tailq: RTE_MBUF_DYNFIELD
>> > 6: [ovn-northd() [0x422a4e]]
>> > 5: [/lib64/libc.so.6(__libc_start_main+0x78) [0x7f44f6d65d18]]
>> > 4: [ovn-northd() [0x6451ed]]
>> > 3: [ovn-northd() [0x418da0]]
>> > 2: [ovn-northd(__rte_panic+0xba) [0x419323]]
>> > 1: [ovn-northd(rte_dump_stack+0x1b) [0x62f10b]]
>> > /usr/local/share/openvswitch/scripts/ovs-lib: line 602: 582595 Aborted 
>> > (core dumped) "$@"
>> >[FAILED]
>> >
>> > Steps to reproduce:
>> > 1. Build and install DPDK v21.11.
>> > meson build
>> > cd build; ninja; ninja install; ldconfig
>> > 2. Build and install OVS with DPDK static libraries.
>> > ./boot.sh
>> > mkdir _gcc  && cd _gcc
>> > ../configure --with-dpdk=static
>> > make -C _gcc && make -C _gcc install
>> >
>> > [root@dell-r640-033 dpdk]# ovs-vsctl get Open_vSwitch . dpdk_version
>> > "DPDK 21.11.0"
>> >
>> > [root@dell-r640-033 dpdk]# ovs-vswitchd --version
>> > ovs-vswitchd (Open vSwitch) 3.0.90
>> > DPDK 21.11.0
>> > 3. Build and install OVN with built OVS.
>> > ./boot.sh
>> > ./configure --with-ovs-source=/usr/local/src/ovs/ 
>> > --with-ovs-build=/usr/local/src/ovs/_gcc
>> > make; make install
>> > 4. Start ovn northd
>> > ovn-ctl start_northd
>> >
>> > I'm on the latest commit of OVN - 45f04d88ae8fa6217812abdaa623d66b05fc7b6a
>> >
>> > Please let me know if any more details are needed. I'm not sure what's 
>> > missing here to get OVN working.
>> >
>>
>> I think the crash is because OVN is compiled with OVS and DPDK.  There
>> is no need to configure OVS with dpdk for OVN compilation.
>>
>> Can you please try using the OVS submodule for OVN compilation ?
>>
>> i.e After cloning OVN
>>
>> cd 
>> git submodule init ovs
>> git submodule update ovs
>> cd ovs
>> ./configure
>> make -j5
>> cd ..
>> ./configure
>> make -j5
>> make install
>>
>> If you don't specify "--with-ovs-source", ovs submodule path will be used.
>>
>> Please note that ovs submodule is used only for OVN compilation.
>>
>> Thanks
>> Numan
>>
>>
>> > Regards,
>> > Spoorthi
>> > ___
>> > discuss mailing list
>> > disc...@openvswitch.org
>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN is crashing with 'ovn-ctl start_northd'

[Numan Siddique via discuss]

On Sat, Nov 12, 2022 at 9:57 PM Spoorthi K via discuss
 wrote:
>
> Hi,
>
> I have installed OVN from source and tried to start northd and ended up with 
> the following crash. Couldn't someone please point out what's going wrong 
> here?
>
> [root@dell-r640-033 ovn]# ovn-ctl start_northd
> Starting ovsdb-nb  [  OK  ]
> EAL: RTE_MBUF_DYNFIELD tailq is already registered
> PANIC in tailqinitfn_mbuf_dynfield_tailq():
> Cannot initialize tailq: RTE_MBUF_DYNFIELD
> 6: [ovn-nbctl() [0x42129e]]
> 5: [/lib64/libc.so.6(__libc_start_main+0x78) [0x7f8f5f9a6d18]]
> 4: [ovn-nbctl() [0x6252cd]]
> 3: [ovn-nbctl() [0x418c01]]
> 2: [ovn-nbctl(__rte_panic+0xba) [0x419184]]
> 1: [ovn-nbctl(rte_dump_stack+0x1b) [0x60f1eb]]
> /usr/local/share/ovn/scripts/ovn-ctl: line 154: 582562 Aborted
>  (core dumped) $(echo ovn-${db}ctl | tr _ -) --no-leader-only 
> --db="unix:$sock" init
> Starting ovsdb-sb  [  OK  ]
> EAL: RTE_MBUF_DYNFIELD tailq is already registered
> PANIC in tailqinitfn_mbuf_dynfield_tailq():
> Cannot initialize tailq: RTE_MBUF_DYNFIELD
> 6: [ovn-sbctl() [0x4212de]]
> 5: [/lib64/libc.so.6(__libc_start_main+0x78) [0x7f0e383b2d18]]
> 4: [ovn-sbctl() [0x5f5e8d]]
> 3: [ovn-sbctl() [0x418c06]]
> 2: [ovn-sbctl(__rte_panic+0xba) [0x419189]]
> 1: [ovn-sbctl(rte_dump_stack+0x1b) [0x5dfdab]]
> /usr/local/share/ovn/scripts/ovn-ctl: line 154: 582588 Aborted
>  (core dumped) $(echo ovn-${db}ctl | tr _ -) --no-leader-only 
> --db="unix:$sock" init
> Starting ovn-northd EAL: RTE_MBUF_DYNFIELD tailq is already registered
> PANIC in tailqinitfn_mbuf_dynfield_tailq():
> Cannot initialize tailq: RTE_MBUF_DYNFIELD
> 6: [ovn-northd() [0x422a4e]]
> 5: [/lib64/libc.so.6(__libc_start_main+0x78) [0x7f44f6d65d18]]
> 4: [ovn-northd() [0x6451ed]]
> 3: [ovn-northd() [0x418da0]]
> 2: [ovn-northd(__rte_panic+0xba) [0x419323]]
> 1: [ovn-northd(rte_dump_stack+0x1b) [0x62f10b]]
> /usr/local/share/openvswitch/scripts/ovs-lib: line 602: 582595 Aborted
>  (core dumped) "$@"
>[FAILED]
>
> Steps to reproduce:
> 1. Build and install DPDK v21.11.
> meson build
> cd build; ninja; ninja install; ldconfig
> 2. Build and install OVS with DPDK static libraries.
> ./boot.sh
> mkdir _gcc  && cd _gcc
> ../configure --with-dpdk=static
> make -C _gcc && make -C _gcc install
>
> [root@dell-r640-033 dpdk]# ovs-vsctl get Open_vSwitch . dpdk_version
> "DPDK 21.11.0"
>
> [root@dell-r640-033 dpdk]# ovs-vswitchd --version
> ovs-vswitchd (Open vSwitch) 3.0.90
> DPDK 21.11.0
> 3. Build and install OVN with built OVS.
> ./boot.sh
> ./configure --with-ovs-source=/usr/local/src/ovs/ 
> --with-ovs-build=/usr/local/src/ovs/_gcc
> make; make install
> 4. Start ovn northd
> ovn-ctl start_northd
>
> I'm on the latest commit of OVN - 45f04d88ae8fa6217812abdaa623d66b05fc7b6a
>
> Please let me know if any more details are needed. I'm not sure what's 
> missing here to get OVN working.
>

I think the crash is because OVN is compiled with OVS and DPDK.  There
is no need to configure OVS with dpdk for OVN compilation.

Can you please try using the OVS submodule for OVN compilation ?

i.e After cloning OVN

cd 
git submodule init ovs
git submodule update ovs
cd ovs
./configure
make -j5
cd ..
./configure
make -j5
make install

If you don't specify "--with-ovs-source", ovs submodule path will be used.

Please note that ovs submodule is used only for OVN compilation.

Thanks
Numan


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

Re: [ovs-discuss] Do OVS flows persist in the kernel if ovn-controller is stopped

[Numan Siddique via discuss]

On Tue, Oct 11, 2022 at 3:31 PM Dan Williams  wrote:
>
> On Fri, 2022-10-07 at 13:51 +0100, Brendan Doyle wrote:
> > Hi Folks,
> >
> > Apologies if this is a dumb question I'm not too familiar with the
> > what goes on between ovn-controller and the kernel OVS flows.
> >
> > So ovn-controller is control plane, the OVS flows it get pushed
> > down to the kernel (the data plane). So I expected that if ovn-
> > controller
> > is stopped on a hypervisor that the dataplane flows would persist in
> > the kernel.
> >
> > But what I see is if I have a VM on hypervisor A and a gateway on
> > hypervisor B. If I stop  ovn-controller on hypervisor A then I can
> > no longer access the VM via the gateway.  There is no Geneve
> > traffic sent to hypervisor A.
>
> Stopping ovn-controller shouldn't flush OVS flows as reported by "ovs-
> ofctl dump-flows br-int". And if the OVS flows don't get flushed I
> wouldn't expect data plane flows to get flushed either.

Although the datapath flows would eventually expire if those flows are
idle for 10 seconds (I think).

Also when you stop ovn-controller either using systemd or using
ovn-ctl stop_controller, before exiting
it deletes all the tunnel interfaces from the "br-int".  I'd presume
this causes ovs-vswitchd revalidator thread to
delete the datapath flows related to the tunnels.

If you don't want ovn-controller do the cleanup, you can pass the
option "--restart" while stopping ovn-controller -
/usr/share/ovn/scripts/ovn-ctl stop_controller --restart
This would also preserve the datapath flows until ovs-vswitchd
revalidator thread expires them.

Thanks
Numan


> There used to be an issue when the new ovn-controller started and
> flushed some flows before it had completely downloaded the Southbound
> DB but that's been fixed by:
>
> http://patchwork.ozlabs.org/project/ovn/list/?series=314426&archive=both&state=*
>
> What version of OVN are you running? Can you dump flows on br-int, then
> stop ovn-controller, then dump flows again and compare? (use --no-stats
> to make diffing easier).
>
> Dan
>
> >
> > I guess as expected CENTRAL has taken hypervisor A out of the
> > Southbound DB, regenerated flows and updated hypervisor B.
> > I thought that the OVS flows might persist in the kernel in
> > hypervisor A and CENTRAL would use the last known location of the
> > VM and not regenerate flows and still tunnel from the gateway on B
> > to A. But I guess not, but it does seem odd that the control plane
> > going down breaks the data plane.
> >
> > Brendan.
> >
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN 21.12 and external ports

[Numan Siddique]

On Thu, Oct 6, 2022 at 4:27 AM Michał Nasiadka  wrote:
>
> Hello,
>
> I’m running OpenStack Wallaby and using Ironic for Bare Metal provisioning.
> Neutron creates External ports for bare metal instances and uses 
> ha_chassis_group.
> Neutron normally defines a different priority for Routers LRP gateway chassis 
> and ha_chassis_group.
>
> I have a router with two VLANs attached - external (used for internet 
> connectivity - SNAT or DNAT/Floating IP) and internal VLAN network hosting 
> bare metal servers (and some Geneve networks for VMs).
>
> If an External port’s HA chassis group active chassis is different than 
> gateway chassis (external vlan network) active chassis - those bare metal 
> servers have intermittent network connectivity for any traffic going through 
> that router.
>
> Is that desired effect in OVN?

I think it would cause some issues.  I'm not able to exactly recall
why, but I've seen similar behavior and it is recommended that the
same controller which is actively handling the gateway traffic also
handles the external ports.  Maybe there is mac flapping of the router
port ips.
That could be the issue.  You can perhaps arp for the router ip from
your bare metal machine and see if you get 2 arp replies - one from
the controller which binds the external port and one from the gateway
chassis controller.

Thanks
Numan



>
> Best regards,
> Michal Nasiadka
>
>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [OVN] Neighbor Advertisements on router failover

[Numan Siddique]

On Mon, Sep 26, 2022 at 11:00 AM Felix Hüttner via discuss
 wrote:
>
> Hi everyone,
>
> We observe the following situation:
> - We have a logical-router bound to two gateway-chassis
> - The logical-router-port connected to the physical network has an ipv4 
> address assigned
>
> When we now failover the router (e.g. by changing the priorities) we can 
> observe GARP packets being send out and updating the mac address tables on 
> the physical switches.
>
> If the logical-router-port is now changed from having an ipv4 address to an 
> ipv6 address then failover does not trigger neighbor advertisements.
> This means that the mac address tables on our physical switches are not 
> updated and require manual intervention for traffic to be working again.
>
> We are now unsure if this is a misconfiguration on our side, or a missing 
> feature in the ovn-controller.

Looks like a  missing feature to me.

Thanks
Numan

>
> Versions:
> ovn-controller 22.03.1
> Open vSwitch Library 2.17.90
> OpenFlow versions 0x6:0x6
> SB DB Schema 20.21.0
>
> Thanks for your feedback
>
> --
> Felix Huettner
>
> Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die 
> Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der 
> vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in 
> Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie 
> hier.
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Guidance on how to use LoadBalancer in OVN

[Numan Siddique]

On Thu, Sep 8, 2022 at 3:59 AM Moiz Ibrahim Randhikpurwala (IT) via
discuss  wrote:
>
> Hi
>
>
>
> We are trying to use the Load Balancer feature in OVN and unable to succeed, 
> need some guidance on how to go about it
>
>
>
> We have a switch which is connected to external network and has several ports 
> attached to it.
>
>
>
> The LB details are as follows
>
> UUIDLB  PROTO  VIP
>  IPs
>
> 0f8ef238-2d7b-4108-a30f-255a380cad7flb0 tcp
> 10.119.34.112:8010.119.34.100:80
>
>
>
> We added the LB to the switch using the below command
>
> ovn-nbctl ls-lb-add de8915f3-ef82-4798-a6c0-5b01aadc22d3 lb0
>
>
>
> Right after running the command all communication to the vms is affected and 
> the load balancer also doesn’t work on that VIP Ip. What am I doing wrong or 
> what all objects I need to create to create a load balancer on OVN.

How are you reaching the VIP ?  Is it from outside i.e from the
external network or from the VMs attached to your logical switch ?

Is your logical switch connected to a logical router ?  If not, you
need to create a logical router and connect it to your logical switch
so that when your VM ARPs for the VIP,
the router port mac is replied.

Otherwise you can create a manual ARP entry in your VM or in the
source which sends the traffic to the VIP.

Thanks
Numan

>
>
>
> Moiz R
>
>
>
>
>
> DISCLAIMER: This e-mail message including any of its attachments is intended 
> solely for the addressee(s) and may contain privileged information. If you 
> are not the addressee or you have received this email message in error, 
> please notify the sender who will remove your details from its database. You 
> are not authorized to read, copy, disseminate, distribute or use this e-mail 
> message or any attachment to it in any manner and must delete the email and 
> destroy any hard copies of it. This e-mail message does not contain financial 
> instructions or commitments of any kind. Any views expressed in this message 
> are those of the individual sender and do not necessarily reflect the views 
> of Emirates NBD PJSC, or any other related subsidiaries, entities or persons.
>
> Emirates NBD Bank (P.J.S.C.) is licensed by the Central Bank of the UAE.
> .بنك الإمارات دبي الوطني ش.م.ع. هو بنك مرخّص من قبل مصرف الإمارات العربية 
> المتحدة المركزي DISCLAIMER: This e-mail message including any of its 
> attachments is intended solely for the addressee(s) and may contain 
> privileged information. If you are not the addressee or you have received 
> this email message in error, please notify the sender who will remove your 
> details from its database. You are not authorized to read, copy, disseminate, 
> distribute or use this e-mail message or any attachment to it in any manner 
> and must delete the email and destroy any hard copies of it. This e-mail 
> message does not contain financial instructions or commitments of any kind. 
> Any views expressed in this message are those of the individual sender and do 
> not necessarily reflect the views of Emirates NBD PJSC, or any other related 
> subsidiaries, entities or persons.
>
> Emirates NBD Bank (P.J.S.C.) is licensed by the Central Bank of the UAE.
> .بنك الإمارات دبي الوطني ش.م.ع. هو بنك مرخّص من قبل مصرف الإمارات العربية 
> المتحدة المركزي
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovn] Unable to configure LB with same VIP as DGP's IP

[Numan Siddique]

On Wed, Aug 31, 2022 at 4:04 PM Numan Siddique  wrote:
>
> On Tue, Aug 30, 2022 at 5:42 AM Vladislav Odintsov  wrote:
> >
> > Hi,
> >
> > I’ve got 1 LR, let say lr1. To this LR two LSs are connected: ls-int 
> > (192.168.0.1/24) with VIF 192.168.0.10 and ls-ext (172.16.0.1/24).
> > On ls-ext’s GW LRP I’ve set gateway chassis. Localnet port is present in 
> > ls-ext to connect lr1 to external network.
> > Also, I've created tcp load balancer: VIP=172.16.0.1:179 with backend 
> > 192.168.0.10:179 and attached it to LR.
> >
> > Next in lr_in_ip_input stage this traffic is dropped as it is destined to 
> > LRP’s IP. ovn-detrace showed explicit DROP lflow in lr_in_ip_input stage 
> > (ip4.dst == {172.16.0.1}, action=drop).
> > I’ve also tried to attach LB to LS, but traffic coming from localnet port 
> > skips conntrack in LS pipeline, IIUC.
> >
> > I wonder if having load balancer VIP’s IP part equal to DGP’s IP is not 
> > supported? If it is so, why?
>
> It does support.  But you need to add an SNAT entry to the logical router.
>
> Eg.  ovn-nbctl lr-nat-add lr1 snat 172.16.0.1 192.168.0.1/24
>
> I tested it and it works for me provided there is an SNAT entry for
> the router port ip connecting to the ls-ext.
>
> If you see the code here [2],  the flow to drop the router ip in
> "lr_in_ip_input" is NOT added if the router ip is an SNAT ip.

Maybe we should fix this in northd.c to not add the drop flow if the
router ip is used as VIP.

Numan

>
> [2] - https://github.com/ovn-org/ovn/blob/main/northd/northd.c#L10666
>
> Thanks
> Numan
>
> >
> > [1]: 
> > https://github.com/ovn-org/ovn/blob/a7c7d4519e5047232045881bf3af3788eb277a16/northd/northd.c#L5848-L5852
> >
> > Regards,
> > Vladislav Odintsov
> >
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN load balancer problem of health check

[Numan Siddique]

On Wed, Aug 31, 2022 at 1:03 PM wangchuanlei  wrote:
>
>   As known to us, if load balancer is used on router, it is centralized.
> If the centralized node loses connection to the compute nodes,
> the vip is still on the centralized node, at this time, the vip should
> not forward packets to backends which on the compute nodes,
> right ?
>

The job of the health check in the ovn-controller is to see if the
backend service is really up or not.

The scenario you mentioned is different.  In your case it's not the
service which is down but the communication
between the nodes is lost.  OVN enables BFD tunnel on the geneve
tunnels to provide HA for the gateway ports
but not for the load balancer VIPs.

Perhaps you can use the "Forwarding Group" feature of OVN for your use
case ?  I'm not sure.
Check this commit [1] and the relevant documentation/test cases on how
to use this feature.
If liveness is enabled on a forwarding group,  then OVN uses "select"
to load balance between the ports
of the forwarding group and it also uses "watch_port".

Maybe we can add the support of "watch_port" for the OVN load
balancers.  This needs some investigation.
Please feel free to explore this in OVN if you've the bandwidth.

Thanks
Numan


Check out this commit
> Thanks
> wangchuanlei
>
>
> On Thu, Aug 25, 2022 at 9:54 PM wangchuanlei  wrote:
> >
> > Hi,
> >   For ovn load-balancer(lb), health check is check the status between
> > vip and backends. Packet is sent by controller to backends, then
> > backends sent a reply, to accomplish the process of healhy check.
> >
> >   On my enviroment, i have two nodes,one is center node, and the other
> > is compute node,  so both of them has a controller, controller sends
> > packet to backends which on its own node. Here, if the center  lost
> > connection to the node,the status of health check still keep online!
> > Because the status are stored in south databse of center.
> > In this case, if vip forward the request from client to the backend
> > which is on the node, the client would not get a reply, so , here is
> > bug!
>
> I'm not sure if this is a bug. If the compute node loses the connection to the
> Southbound database, it can't update the health check status.
> >
> >   As the health check is distributed on controller, should change to
> > be centralization ?
>
> I don't think that would help.  What if the centralized node which does the
> health check loses connection to the compute nodes ?
>
> Thanks
> Numan
>
> >
> > Thanks!
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovn] Unable to configure LB with same VIP as DGP's IP

[Numan Siddique]

On Tue, Aug 30, 2022 at 5:42 AM Vladislav Odintsov  wrote:
>
> Hi,
>
> I’ve got 1 LR, let say lr1. To this LR two LSs are connected: ls-int 
> (192.168.0.1/24) with VIF 192.168.0.10 and ls-ext (172.16.0.1/24).
> On ls-ext’s GW LRP I’ve set gateway chassis. Localnet port is present in 
> ls-ext to connect lr1 to external network.
> Also, I've created tcp load balancer: VIP=172.16.0.1:179 with backend 
> 192.168.0.10:179 and attached it to LR.
>
> Next in lr_in_ip_input stage this traffic is dropped as it is destined to 
> LRP’s IP. ovn-detrace showed explicit DROP lflow in lr_in_ip_input stage 
> (ip4.dst == {172.16.0.1}, action=drop).
> I’ve also tried to attach LB to LS, but traffic coming from localnet port 
> skips conntrack in LS pipeline, IIUC.
>
> I wonder if having load balancer VIP’s IP part equal to DGP’s IP is not 
> supported? If it is so, why?

It does support.  But you need to add an SNAT entry to the logical router.

Eg.  ovn-nbctl lr-nat-add lr1 snat 172.16.0.1 192.168.0.1/24

I tested it and it works for me provided there is an SNAT entry for
the router port ip connecting to the ls-ext.

If you see the code here [2],  the flow to drop the router ip in
"lr_in_ip_input" is NOT added if the router ip is an SNAT ip.

[2] - https://github.com/ovn-org/ovn/blob/main/northd/northd.c#L10666

Thanks
Numan

>
> [1]: 
> https://github.com/ovn-org/ovn/blob/a7c7d4519e5047232045881bf3af3788eb277a16/northd/northd.c#L5848-L5852
>
> Regards,
> Vladislav Odintsov
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN load balancer problem of health check

[Numan Siddique]

On Thu, Aug 25, 2022 at 9:54 PM wangchuanlei  wrote:
>
> Hi,
>   For ovn load-balancer(lb), health check is check
> the status between vip and backends. Packet is sent
> by controller to backends, then backends sent a reply,
> to accomplish the process of healhy check.
>
>   On my enviroment, i have two nodes,one is center node,
> and the other is compute node,  so both of them has a
> controller, controller sends packet to backends which
> on its own node. Here, if the center  lost connection
> to the node,the status of health check still keep online!
> Because the status are stored in south databse of center.
> In this case, if vip forward the request from client to
> the backend which is on the node, the client would
> not get a reply, so , here is bug!

I'm not sure if this is a bug. If the compute node loses the
connection to the Southbound database,
it can't update the health check status.
>
>   As the health check is distributed on controller,
> should change to be centralization ?

I don't think that would help.  What if the centralized node which
does the health check
loses connection to the compute nodes ?

Thanks
Numan

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

Re: [ovs-discuss] Is OVS right for me?

[Numan Siddique]

On Mon, Aug 22, 2022 at 2:16 AM Anders Östling  wrote:
>
> I need an advise from you guys. I used to have a mikrotik router where one of 
> the ports was assigned a subnet that I used for hosting a number of virtual 
> machines (lab, not production). That router is since replaced with a switch 
> connected to my main local network, so now I am unable to (in an easy way) 
> have a routed network.
>
> What if I install OVS on the host, and creates a 10.0.2.0/24 network there 
> for the VM's? Would that give my the same logical setup as before? I'm no 
> stranger to networking, but a total newbie concerning OVS. But not afraid to 
> read, listen and learn. Should I go for it?
>
> My current host is on a 192.168.88.0/24 network and using a bridge so that 
> the VM's can talk to each other and the outside world. However, I would love 
> to have them back on 10.0.2.0/24 so that I can have ip's that matches another 
> site where the production system resides. My host is an Ubuntu 22.04 on ZFS.
>
> Maybe there are other solution that works, but learning OVS would also be fun.
>
> Let me know what you think!

I think you can definitely use OVS and create VMs which would have IPs
configured from the subnet 10.0.2.0/24.  Although I'm not clear
on how they can communicate with your production system.

I'd suggest giving it a try.  Also seems to me you can use OVN along
with OVS to make it much easier.
With OVN, you can create a logical switch with subnet - 10.0.2.0/24
and attach a logical router to it.


Thanks
Numan

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

Re: [ovs-discuss] [External] : UDP stateful ACL not working when pkt passing through two switches ?

[Numan Siddique]

On Tue, Aug 9, 2022 at 6:37 PM Brendan Doyle  wrote:
>
>
>
> On 09/08/2022 03:14, Numan Siddique wrote:
> > On Mon, Aug 8, 2022 at 7:39 PM Brendan Doyle  
> > wrote:
> >> Did not see a response so sending again, am I missing something here, or 
> >> is it a bug?
> >>
> >> Thanks
> >> Brendan
> >>
> >> On 28/07/2022 19:53, Brendan Doyle wrote:
> >>
> >> UDP stateful ACL not working? The logical representation of My network  is 
> >> shown bellow
> >> ('ovn-nbctl show' shown towards the end). I have a Port Group 
> >> (pg_vcn3_net1_sl3) that has
> >> two ports in it, the VM port on switch(ls_vcn3_net1) and 
> >> lsb_vcn4_stgw-lr_vcn3_stgw switch
> >> (ls_vcn3_backbone) asshown below ((o)).
> > The port 'lsb_vcn4_stgw-lr_vcn3_stgw' is a router port right ?  (i.e
> > it is a patch port connecting to lr_vcn3_stgw router).
> Yes it is
> > If the inport or outport is a router port, ovn-northd adds the flows
> > to skip the conntrack.
>
> Why? and is there a way around it? bar adding a switch between
> ls_vcn3_backbone
> and lr_vcn3_stgw :
>
>   +-+
>   |   ls_vcn3_backbone|
>   +((O))+
>  | lsb_vcn4_stgw-lr_vcn3_stgw in PG pg_vcn3_net1_sl3
>  |
> ++
> |  ls_vcn3_gw_join   | <<-- New switch just so ACLs on
> lsb_vcn4_stgw-lr_vcn3_stgw get applied
>  +---+
>  |
>  | lr_vcn3_stgw-lsb_vcn3_stgw (253.255.25.10/25)
>/\
>   ( lr_vcn3_stgw ) SNAT 192.16.1.6 to 253.255.80.8
>\-/
>
>
> The problem I have is that lr_vcn3_stgw provides access to an NFS server
> in the
> underlay, but that NFS server is "made available" at an IP in the overlay by
> having ls_vcn3_net1  do proxy ARP for the overlay NFS server IP address.
>
> I need the NFS server to be in the same Port Group that is created for the
> all IPs in the subnet associated with  ls_vcn3_net1/lr_vcn3_net1 as if
> it were
> on a VM directly connected to ls_vcn3_net1.
>

I don't think there is a work around and we may have to add this
support in ovn-northd.
ACLs are generally applied to VIF ports and I think that's why it was
skipped for router ports.
If we have to add the support, this should be carefully designed and
tested thoroughly.
As this may incur additional conntrack recirculations and may even
break hardware offloading.

Thanks
Numan

> Thanks
>
> Brendan
>
>
>
> > Thanks
> > Numan
> >
> >> I do a 'showmount -e 192.16.1.106' in the VM, I see the pkt go out from 
> >> the VM  get to the NFS
> >> server on the underlay, see the reply on the underlay and then I see my PG 
> >> ACL drop the pkt.
> >>
> >> The ACLs are:
> >>
> >> Egress From VM - Ingress to switch
> >> ---
> >> from-lport 32767 (inport == @pg_vcn3_net1_sl3 && (arp || udp.dst == 67 || 
> >> udp.dst == 68)) allow-related
> >> from-lport 27000 (inport == @pg_vcn3_net1_sl3 && ip4.dst == 192.16.1.0/24 
> >> && udp.dst == 111) allow-related
> >> from-lport 0 (inport == @pg_vcn3_net1_sl3) drop 
> >> log(name=fss-8,severity=debug) <--- Drops 
> >> the return pkt
> >>
> >> Ingress TO VM - Egress from switch
> >> 
> >>to-lport 32767 (outport == @pg_vcn3_net1_sl3 && (arp || udp.dst == 67 
> >> || udp.dst == 68)) allow-related
> >>to-lport 27000 (outport == @pg_vcn3_net1_sl3 && ip4.src == 
> >> 192.16.1.0/24 && tcp.dst == 111) allow-related
> >>to-lport 27000 (outport == @pg_vcn3_net1_sl3 && ip4.src == 
> >> 192.16.1.0/24 && tcp.dst == 20048) allow-related
> >>to-lport 27000 (outport == @pg_vcn3_net1_sl3 && ip4.src == 
> >> 192.16.1.0/24 && udp.dst == 111) allow-related  <--- But this should
> >>to-lport 0 (outport == @pg_vcn3_net1_sl3) drop 
> >> log(name=fss-17,severity=debug)
> >>have allowed the
> >>
> >>
> >>   

Re: [ovs-discuss] [OVN] Dynamic MAC address learning with port security enabled

[Numan Siddique]

On Thu, Aug 11, 2022 at 1:06 AM Renat Nurgaliyev  wrote:
>
> Hi all,
>
> If I understand correctly, OVN Logical Switches will learn MAC
> addresses and store them in the FDB table only on ports with port
> security disabled. If the port security is enabled on a port,
> configured addresses are used instead to make forwarding decisions.
>
> What are possible cons of having both port security, and dynamic MAC
> learning? This could be nice in some situations when MAC moves between
> ports, for example if VRRP is used. Such toggle flag could be
> implemented on a logical switch-basis, to prevent unecessary growth of
> the FDB table.
>
> Or maybe I am missing something, and VRRP with a virtual MAC address
> can be implemented without forcing dynamic MAC learning? During tests
> I could not force traffic towards virtual MAC to steer to another
> port, although GARP was sent. Disabling port security and switching to
> dynamic MAC learning immediately solved the problem.
>
> Any help is appreciated!

I think you can use logical ports of type - virtual for your use case.
That's how Openstack
Neutron supports octavia amphora load balancer VMs.

You just need to create a logical port of type virtual and configure
its parents.  And ovn will bind
this virtual port to the parent port/VM when it sees an ARP packet.

Please refer to this - https://github.com/ovn-org/ovn/blob/main/ovn-nb.xml#L1114
and the OVN test cases for virtual ports to better understand the usage.
Grep for  "AT_SETUP([virtual ports])"  here
https://raw.githubusercontent.com/ovn-org/ovn/main/tests/ovn.at

Thanks
Numan


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

Re: [ovs-discuss] [External] : UDP stateful ACL not working when pkt passing through two switches ?

[Numan Siddique]

On Mon, Aug 8, 2022 at 7:39 PM Brendan Doyle  wrote:
>
> Did not see a response so sending again, am I missing something here, or is 
> it a bug?
>
> Thanks
> Brendan
>
> On 28/07/2022 19:53, Brendan Doyle wrote:
>
> UDP stateful ACL not working? The logical representation of My network  is 
> shown bellow
> ('ovn-nbctl show' shown towards the end). I have a Port Group 
> (pg_vcn3_net1_sl3) that has
> two ports in it, the VM port on switch(ls_vcn3_net1) and 
> lsb_vcn4_stgw-lr_vcn3_stgw switch
> (ls_vcn3_backbone) asshown below ((o)).

The port 'lsb_vcn4_stgw-lr_vcn3_stgw' is a router port right ?  (i.e
it is a patch port connecting to lr_vcn3_stgw router).
If the inport or outport is a router port, ovn-northd adds the flows
to skip the conntrack.

Thanks
Numan

>
> I do a 'showmount -e 192.16.1.106' in the VM, I see the pkt go out from the 
> VM  get to the NFS
> server on the underlay, see the reply on the underlay and then I see my PG 
> ACL drop the pkt.
>
> The ACLs are:
>
> Egress From VM - Ingress to switch
> ---
> from-lport 32767 (inport == @pg_vcn3_net1_sl3 && (arp || udp.dst == 67 || 
> udp.dst == 68)) allow-related
> from-lport 27000 (inport == @pg_vcn3_net1_sl3 && ip4.dst == 192.16.1.0/24 && 
> udp.dst == 111) allow-related
> from-lport 0 (inport == @pg_vcn3_net1_sl3) drop 
> log(name=fss-8,severity=debug) <--- Drops the 
> return pkt
>
> Ingress TO VM - Egress from switch
> 
>   to-lport 32767 (outport == @pg_vcn3_net1_sl3 && (arp || udp.dst == 67 || 
> udp.dst == 68)) allow-related
>   to-lport 27000 (outport == @pg_vcn3_net1_sl3 && ip4.src == 192.16.1.0/24 && 
> tcp.dst == 111) allow-related
>   to-lport 27000 (outport == @pg_vcn3_net1_sl3 && ip4.src == 192.16.1.0/24 && 
> tcp.dst == 20048) allow-related
>   to-lport 27000 (outport == @pg_vcn3_net1_sl3 && ip4.src == 192.16.1.0/24 && 
> udp.dst == 111) allow-related  <--- But this should
>   to-lport 0 (outport == @pg_vcn3_net1_sl3) drop 
> log(name=fss-17,severity=debug)   
> have allowed the
>   
>   
> return pkt
>
>
> ++
> |   VM   |
> | 192.16.1.6 |
> +-((O))--+
> | 284195d2-9280-4334-900e-571ecd00327a in PG pg_vcn3_net1_sl3
>   +-+
>   |ls_vcn3_net1 |
>   +-+
> | ls_vcn3_net1-lr_vcn3_net1 (proxy ARP for 192.16.1.106)
>   |
> |
> | lr_vcn3_net1-ls_vcn3_net1 (192.16.1.1/24)
>   /\
>  ( lr_vcn3_net1 )
>   \/
> | lr_vcn3_net1-lsb_vcn3_net1 (253.255.25.1/25)
> |
> |
> | lsb_vcn3_net1-lr_vcn3_net1
>  ++
>  |   ls_vcn3_backbone |
>  +((O))---+
> | lsb_vcn4_stgw-lr_vcn3_stgw in PG pg_vcn3_net1_sl3
> |
> |
> | lr_vcn3_stgw-lsb_vcn3_stgw (253.255.25.10/25)
>  /\
> ( lr_vcn3_stgw ) SNAT 192.16.1.6 to 253.255.80.8
>  \/
> | lr_vcn3_stgw-ls_vcn3_external_stgw (253.255.80.20/16)
> |
> |
> | ls_vcn3_external_stgw-lr_vcn3_stgw
>   +---+
>   | ls_vcn3_external_stgw |
>   +---+
> | ln-ls_vcn3_external_stgw
> |   (localnet)
> |
>+-+
>| br-ext  | Physical OVS on chassis
>+-+
> |  Egress : Change dst 192.16.1.106 to dst 253.255.0.2
> |  Ingress: Change src 253.255.0.2 to 192.16.1.106
> 253.255.0.0/16  |
> |
>  +---+
>  |  NFS server   |
>  | 253.255.0.2   |
>  +---+
>
> When I do a trace of the out going pkt, it looks like to me that there is no 
> conntrack
> established in the ls_vcn3_backbone so it does not recognize the return pkt 
> as a return
> but the 'allow-related' should have established that. See Below
>
>
> ovn-trace --detailed ls_vcn3_net1 'inport == 
> "284195d2-9280-4334-900e-571ecd00327a" && eth.dst == 40:44:00:00:00:90 && 
> eth.src == 52:54:00:02:55:96 && ip4.src == 192.16.1.6 && ip4.dst == 
> 192.16.1.106 && ip.ttl == 64 && udp.dst == 111'
> # 
> udp,reg14=0x1,vlan_tci=0x,dl_src=52:54:00:02:55:96,dl_dst=40:44:00:00:00:90,nw_src=192.16.1.6,nw_dst=192.16.1.106,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=0,tp_dst=111
>
> ingress(dp="ls_vcn3_net1", inport="284195")
> -

Re: [ovs-discuss] ovn-controller stranger behaviour

[Numan Siddique]

On Mon, Jun 27, 2022 at 1:35 PM Numan Siddique  wrote:
>
> On Mon, Jun 27, 2022 at 12:25 PM Numan Siddique  wrote:
> >
> > On Mon, Jun 27, 2022 at 3:56 AM Dumitru Ceara  wrote:
> > >
> > > On 6/24/22 21:50, Numan Siddique wrote:
> > > > On Fri, Jun 24, 2022 at 11:53 AM ROBERTO BARTZEN ACOSTA via discuss <
> > > > ovs-discuss@openvswitch.org> wrote:
> > > >
> > > >> Hi Dumitru,
> > > >>
> > >
> > > Hi Roberto,
> > >
> > > >> I also think this issue is related to ovn-monitor-all=true but I'm not
> > > >> sure about the CPU usage consequences of disabling this.
> > > >>
> > > >> In OVSDB the changes are tracked and applied to each client in the IDL
> > > >> layer. The OVSDB_IDL_MONITOR is set by default, then the IDL 
> > > >> replicates the
> > > >> changes in the database. Therefore, an OVSDB-IDL transaction modifies 
> > > >> the
> > > >> contents of a database and the client requests information about the
> > > >> incremental changes.
> > > >>
> > > >> The ovn-monitor-all set the condition clause as true in 
> > > >> update_sb_monitors
> > > >> function and enable the monitor for many database information, such as:
> > > >> Port_Bindings rows for local interfaces and local datapaths; Monitor
> > > >> Logical_Flow, MAC_Binding, Multicast_Group, and DNS tables for local
> > > >> datapaths; Monitor Controller_Event rows for local chassis; etc.
> > > >>
> > > >> Using these conditions clauses allows ovn-monitor-all to filter to only
> > > >> replicate when specific conditions are met. However, the default 
> > > >> behavior
> > > >> is different, when the IDL replicates a particular table in the 
> > > >> database,
> > > >> it replicates every row in the table.
> > > >>
> > > >> I would like to better understand the computational advantages of the
> > > >> ovn-controller conditional replication clauses, and the risks of not
> > > >> enabling this parameter in a large-scale solution.
> > > >>
> > > >> Best regards,
> > > >> Roberto
> > > >>
> > > >>
> > > > On large scale deployments,  our testing has shown that - 
> > > > ovn-monitor-all=false
> > > > puts a significant amount of CPU load to the Southbound ovsdb-server as 
> > > > it
> > > > has to conditionally send the data to each ovn-controller.
> > > > And hence we added the option - ovn-monitor-all=true.  Drawback of this 
> > > > is
> > > > that an ovn-controller with ovn-monitor-all=true will get all the DB
> > > > updates.  But this is still better compared to slow southbound 
> > > > ovsdb-server.
> > > >
> > >
> > > Another potential drawback of ovn-monitor-all=true is additional network
> > > traffic (all clients need to get all updates).  But, as Numan mentioned
> > > above, in all our scale testing (both for OpenStack and OpenShift) the
> > > impact of this seems to be less significant compared to the impact on
> > > the Southbound when ovn-monitor-all=false.
> > >
> > >
> > > Numan, to avoid using ovn-monitor-all=false as workaround in this case,
> > > do you think we can port
> > > https://github.com/ovn-org/ovn/commit/0a4e073f4124b58f1b21778ec2293bbc4180e3e0
> > > to branch-21.09 and see if Xena can pick it up?
> > >
> >
> > Given that this commit has fixed a bug,  I think we can backport to
> > older branches.  Looks like its not backported to branch-22.03 as
> > well.
>
> Actually it's already backported till branch-21.12.   I'll backport to
> branch-21.09 once the CI here passes -
> https://github.com/numansiddique/ovn/runs/7077845291?check_suite_focus=true
>

Backport to branch-21.09 done.

Thanks
Numan

> Thanks
> Numan
>
>
> >
> > I'll see if it can be backported easily.
> >
> > Numan
> >
> > > Thanks,
> > > Dumitru
> > >
> > > > Thanks
> > > > Numan
> > > >
> > > >
> > > >
> > > >> Em sex., 24 de jun. de 2022 às 12:13, Tiago Pires 
> > > >> escreveu:
> > > >>
> > > >>> Hi Dumitru,
> > > >>>
> > &

Re: [ovs-discuss] ovn-controller stranger behaviour

[Numan Siddique]

On Mon, Jun 27, 2022 at 12:25 PM Numan Siddique  wrote:
>
> On Mon, Jun 27, 2022 at 3:56 AM Dumitru Ceara  wrote:
> >
> > On 6/24/22 21:50, Numan Siddique wrote:
> > > On Fri, Jun 24, 2022 at 11:53 AM ROBERTO BARTZEN ACOSTA via discuss <
> > > ovs-discuss@openvswitch.org> wrote:
> > >
> > >> Hi Dumitru,
> > >>
> >
> > Hi Roberto,
> >
> > >> I also think this issue is related to ovn-monitor-all=true but I'm not
> > >> sure about the CPU usage consequences of disabling this.
> > >>
> > >> In OVSDB the changes are tracked and applied to each client in the IDL
> > >> layer. The OVSDB_IDL_MONITOR is set by default, then the IDL replicates 
> > >> the
> > >> changes in the database. Therefore, an OVSDB-IDL transaction modifies the
> > >> contents of a database and the client requests information about the
> > >> incremental changes.
> > >>
> > >> The ovn-monitor-all set the condition clause as true in 
> > >> update_sb_monitors
> > >> function and enable the monitor for many database information, such as:
> > >> Port_Bindings rows for local interfaces and local datapaths; Monitor
> > >> Logical_Flow, MAC_Binding, Multicast_Group, and DNS tables for local
> > >> datapaths; Monitor Controller_Event rows for local chassis; etc.
> > >>
> > >> Using these conditions clauses allows ovn-monitor-all to filter to only
> > >> replicate when specific conditions are met. However, the default behavior
> > >> is different, when the IDL replicates a particular table in the database,
> > >> it replicates every row in the table.
> > >>
> > >> I would like to better understand the computational advantages of the
> > >> ovn-controller conditional replication clauses, and the risks of not
> > >> enabling this parameter in a large-scale solution.
> > >>
> > >> Best regards,
> > >> Roberto
> > >>
> > >>
> > > On large scale deployments,  our testing has shown that - 
> > > ovn-monitor-all=false
> > > puts a significant amount of CPU load to the Southbound ovsdb-server as it
> > > has to conditionally send the data to each ovn-controller.
> > > And hence we added the option - ovn-monitor-all=true.  Drawback of this is
> > > that an ovn-controller with ovn-monitor-all=true will get all the DB
> > > updates.  But this is still better compared to slow southbound 
> > > ovsdb-server.
> > >
> >
> > Another potential drawback of ovn-monitor-all=true is additional network
> > traffic (all clients need to get all updates).  But, as Numan mentioned
> > above, in all our scale testing (both for OpenStack and OpenShift) the
> > impact of this seems to be less significant compared to the impact on
> > the Southbound when ovn-monitor-all=false.
> >
> >
> > Numan, to avoid using ovn-monitor-all=false as workaround in this case,
> > do you think we can port
> > https://github.com/ovn-org/ovn/commit/0a4e073f4124b58f1b21778ec2293bbc4180e3e0
> > to branch-21.09 and see if Xena can pick it up?
> >
>
> Given that this commit has fixed a bug,  I think we can backport to
> older branches.  Looks like its not backported to branch-22.03 as
> well.

Actually it's already backported till branch-21.12.   I'll backport to
branch-21.09 once the CI here passes -
https://github.com/numansiddique/ovn/runs/7077845291?check_suite_focus=true

Thanks
Numan


>
> I'll see if it can be backported easily.
>
> Numan
>
> > Thanks,
> > Dumitru
> >
> > > Thanks
> > > Numan
> > >
> > >
> > >
> > >> Em sex., 24 de jun. de 2022 às 12:13, Tiago Pires 
> > >> escreveu:
> > >>
> > >>> Hi Dumitru,
> > >>>
> > >>> I did a test and configuring ovn-monitor-all as false to solve this
> > >>> behaviour.
> > >>> It seems the option I have now is to use it as a workaround until I have
> > >>> conditions to upgrade to Yoga that has OVN 22.03.
> > >>>
> > >>> Thank you for your help.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Tiago Pires
> > >>>
> > >>>
> > >>> Em sex., 24 de jun. de 2022 às 04:27, Dumitru Ceara 
> > >>> escreveu:
> > >>>
> > >>>> On 6/23/22 22:23, Tiago Pires wro

Re: [ovs-discuss] ovn-controller stranger behaviour

[Numan Siddique]

On Mon, Jun 27, 2022 at 3:56 AM Dumitru Ceara  wrote:
>
> On 6/24/22 21:50, Numan Siddique wrote:
> > On Fri, Jun 24, 2022 at 11:53 AM ROBERTO BARTZEN ACOSTA via discuss <
> > ovs-discuss@openvswitch.org> wrote:
> >
> >> Hi Dumitru,
> >>
>
> Hi Roberto,
>
> >> I also think this issue is related to ovn-monitor-all=true but I'm not
> >> sure about the CPU usage consequences of disabling this.
> >>
> >> In OVSDB the changes are tracked and applied to each client in the IDL
> >> layer. The OVSDB_IDL_MONITOR is set by default, then the IDL replicates the
> >> changes in the database. Therefore, an OVSDB-IDL transaction modifies the
> >> contents of a database and the client requests information about the
> >> incremental changes.
> >>
> >> The ovn-monitor-all set the condition clause as true in update_sb_monitors
> >> function and enable the monitor for many database information, such as:
> >> Port_Bindings rows for local interfaces and local datapaths; Monitor
> >> Logical_Flow, MAC_Binding, Multicast_Group, and DNS tables for local
> >> datapaths; Monitor Controller_Event rows for local chassis; etc.
> >>
> >> Using these conditions clauses allows ovn-monitor-all to filter to only
> >> replicate when specific conditions are met. However, the default behavior
> >> is different, when the IDL replicates a particular table in the database,
> >> it replicates every row in the table.
> >>
> >> I would like to better understand the computational advantages of the
> >> ovn-controller conditional replication clauses, and the risks of not
> >> enabling this parameter in a large-scale solution.
> >>
> >> Best regards,
> >> Roberto
> >>
> >>
> > On large scale deployments,  our testing has shown that - 
> > ovn-monitor-all=false
> > puts a significant amount of CPU load to the Southbound ovsdb-server as it
> > has to conditionally send the data to each ovn-controller.
> > And hence we added the option - ovn-monitor-all=true.  Drawback of this is
> > that an ovn-controller with ovn-monitor-all=true will get all the DB
> > updates.  But this is still better compared to slow southbound ovsdb-server.
> >
>
> Another potential drawback of ovn-monitor-all=true is additional network
> traffic (all clients need to get all updates).  But, as Numan mentioned
> above, in all our scale testing (both for OpenStack and OpenShift) the
> impact of this seems to be less significant compared to the impact on
> the Southbound when ovn-monitor-all=false.
>
>
> Numan, to avoid using ovn-monitor-all=false as workaround in this case,
> do you think we can port
> https://github.com/ovn-org/ovn/commit/0a4e073f4124b58f1b21778ec2293bbc4180e3e0
> to branch-21.09 and see if Xena can pick it up?
>

Given that this commit has fixed a bug,  I think we can backport to
older branches.  Looks like its not backported to branch-22.03 as
well.

I'll see if it can be backported easily.

Numan

> Thanks,
> Dumitru
>
> > Thanks
> > Numan
> >
> >
> >
> >> Em sex., 24 de jun. de 2022 às 12:13, Tiago Pires 
> >> escreveu:
> >>
> >>> Hi Dumitru,
> >>>
> >>> I did a test and configuring ovn-monitor-all as false to solve this
> >>> behaviour.
> >>> It seems the option I have now is to use it as a workaround until I have
> >>> conditions to upgrade to Yoga that has OVN 22.03.
> >>>
> >>> Thank you for your help.
> >>>
> >>> Regards,
> >>>
> >>> Tiago Pires
> >>>
> >>>
> >>> Em sex., 24 de jun. de 2022 às 04:27, Dumitru Ceara 
> >>> escreveu:
> >>>
> >>>> On 6/23/22 22:23, Tiago Pires wrote:
> >>>>> Hi all,
> >>>>>
> >>>>
> >>>> Hi Tiago,
> >>>>
> >>>>> I did some troubleshooting and I'm seeing this error (ovs-vswitchd)
> >>>> always
> >>>>> when a VM is created in a Chassi:
> >>>>> 2022-06-23T11:47:08.385Z|07907|bridge|WARN|could not open network
> >>>> device
> >>>>> tap8a43df0c-fd (No such device)
> >>>>> 2022-06-23T11:47:09.282Z|07908|bridge|INFO|bridge br-int: added
> >>>> interface
> >>>>> tap8a43df0c-fd on port 51
> >>>>> 2022-06-23T11:47:09.645Z|07909|bridge|INFO|bridge br-int: added
> >>>> interface
> >>&g

Re: [ovs-discuss] ovn-controller stranger behaviour

[Numan Siddique]

On Fri, Jun 24, 2022 at 11:53 AM ROBERTO BARTZEN ACOSTA via discuss <
ovs-discuss@openvswitch.org> wrote:

> Hi Dumitru,
>
> I also think this issue is related to ovn-monitor-all=true but I'm not
> sure about the CPU usage consequences of disabling this.
>
> In OVSDB the changes are tracked and applied to each client in the IDL
> layer. The OVSDB_IDL_MONITOR is set by default, then the IDL replicates the
> changes in the database. Therefore, an OVSDB-IDL transaction modifies the
> contents of a database and the client requests information about the
> incremental changes.
>
> The ovn-monitor-all set the condition clause as true in update_sb_monitors
> function and enable the monitor for many database information, such as:
> Port_Bindings rows for local interfaces and local datapaths; Monitor
> Logical_Flow, MAC_Binding, Multicast_Group, and DNS tables for local
> datapaths; Monitor Controller_Event rows for local chassis; etc.
>
> Using these conditions clauses allows ovn-monitor-all to filter to only
> replicate when specific conditions are met. However, the default behavior
> is different, when the IDL replicates a particular table in the database,
> it replicates every row in the table.
>
> I would like to better understand the computational advantages of the
> ovn-controller conditional replication clauses, and the risks of not
> enabling this parameter in a large-scale solution.
>
> Best regards,
> Roberto
>
>
On large scale deployments,  our testing has shown that - ovn-monitor-all=false
puts a significant amount of CPU load to the Southbound ovsdb-server as it
has to conditionally send the data to each ovn-controller.
And hence we added the option - ovn-monitor-all=true.  Drawback of this is
that an ovn-controller with ovn-monitor-all=true will get all the DB
updates.  But this is still better compared to slow southbound ovsdb-server.

Thanks
Numan



> Em sex., 24 de jun. de 2022 às 12:13, Tiago Pires 
> escreveu:
>
>> Hi Dumitru,
>>
>> I did a test and configuring ovn-monitor-all as false to solve this
>> behaviour.
>> It seems the option I have now is to use it as a workaround until I have
>> conditions to upgrade to Yoga that has OVN 22.03.
>>
>> Thank you for your help.
>>
>> Regards,
>>
>> Tiago Pires
>>
>>
>> Em sex., 24 de jun. de 2022 às 04:27, Dumitru Ceara 
>> escreveu:
>>
>>> On 6/23/22 22:23, Tiago Pires wrote:
>>> > Hi all,
>>> >
>>>
>>> Hi Tiago,
>>>
>>> > I did some troubleshooting and I'm seeing this error (ovs-vswitchd)
>>> always
>>> > when a VM is created in a Chassi:
>>> > 2022-06-23T11:47:08.385Z|07907|bridge|WARN|could not open network
>>> device
>>> > tap8a43df0c-fd (No such device)
>>> > 2022-06-23T11:47:09.282Z|07908|bridge|INFO|bridge br-int: added
>>> interface
>>> > tap8a43df0c-fd on port 51
>>> > 2022-06-23T11:47:09.645Z|07909|bridge|INFO|bridge br-int: added
>>> interface
>>> > tap3200bf1c-20 on port 52
>>> > 2022-06-23T11:47:19.329Z|07911|connmgr|INFO|br-int<->unix#1468: 430
>>> > flow_mods in the 7 s starting 10 s ago (410 adds, 20 deletes)
>>> >
>>>
>>> It doesn't look to me like there's anything to worry about from these
>>> logs.
>>>
>>> > On this commit
>>> >
>>> http://patchwork.ozlabs.org/project/ovn/patch/1608197000-637-1-git-send-email-dce...@redhat.com/
>>> > it solved something similar to my issue. It seems the ovs-vswitchd is
>>> > missing some flows and when I run the recompute it fixes it.
>>> > So, to avoid this issue I'm testing at this moment to run the recompute
>>> > through libvirt hook when a VM gets "started" status.
>>> >
>>>
>>> While this might "fix" the issue it's not really ideal.  ovn-controller
>>> should properly install the flows all the time.  Otherwise it's a bug.
>>>
>>> > Regards,
>>> >
>>> > Tiago Pires
>>> >
>>> >
>>> > Em qua., 22 de jun. de 2022 às 19:43, Tiago Pires 
>>> > escreveu:
>>> >
>>> >> Hi all,
>>> >>
>>> >> I'm trying to understand a stranger's behaviour regarding to
>>> >> ovn-controller.
>>> >> In my setup I have OVN 21.09/ OVS 2.16 and Xena and sometimes when a
>>> new
>>> >> VM is created, this VM can reach other VMs in east-west traffic (even
>>> in
>>> >> differents Chassis) but it can't reach an external network (e.g.
>>> Internet)
>>> >> through Chassi Gateway.
>>> >> I ran the following trace:
>>> >> # ovs-appctl ofproto/trace br-int
>>> >>
>>> in_port="93",icmp,dl_src=fa:16:3e:26:34:ef,dl_dst=fa:16:3e:65:68:6e,nw_src=192.168.40.140,nw_dst=8.8.8.8,nw_ttl=64
>>> >>
>>> >> And I got this output:
>>> >> Final flow:
>>> >>
>>> recirc_id=0xc157b1,eth,icmp,reg0=0x300,reg11=0xd,reg12=0x10,reg13=0xf,reg14=0x3,reg15=0x2,metadata=0x29,in_port=93,vlan_tci=0x,dl_src=fa:16:3e:26:34:ef,dl_dst=fa:16:3e:65:68:6e,nw_src=192.168.40.140,nw_dst=8.8.8.8,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=0,icmp_code=0
>>> >> Megaflow:
>>> >>
>>> recirc_id=0xc157b1,ct_state=+new-est-rel-rpl-inv+trk,ct_label=0/0x1,eth,icmp,in_port=93,dl_src=fa:16:3e:26:34:ef,dl_dst=fa:16:3e:65:68:6e,nw_src=
>>> >> 192.168.40.128/26,nw_dst=8.0.0.0/7,nw_ttl=64,n

Re: [ovs-discuss] OVN: VTEP gateway and Logical Router

[Numan Siddique]

On Mon, Jun 20, 2022 at 6:18 PM Sergey  wrote:
>
> Hello!
>
> We use VTEP gateway to extend OVN Geneve network to VXLAN on physical 
> switches.
> It works great, VMs and baremetals and physical routers see each other.
>
> But when you create a Logical Router in OVN and try to use it from baremetals 
> or physical routers - there is a problem.
> It is unreachable.
>
> So I have a question, maybe there is some solution to solve it? Something 
> similar to "Native OVN services for external logical ports"...
>
> If there is no such solution is it a good idea to solve it by implementing a 
> few OVS rules to solve it?

Does this commit address your usecase -
https://github.com/ovn-org/ovn/commit/4e90bcf55c2ef1ab9940836455e4bfe36e57f307
?

+Vladislav Odintsov   Maybe he has some comments for this use case.

Thanks
Numan

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

Re: [ovs-discuss] What is the best tool for automated testing with openstack?

[Numan Siddique]

On Tue, Jun 14, 2022 at 2:58 PM ROBERTO BARTZEN ACOSTA via discuss <
ovs-discuss@openvswitch.org> wrote:

> Hey there,
>
> I'm using OpenStack(old version) with neutron OVN CMS-plugin and I need to
> migrate to the Yoga release (Ubuntu ovn v22.03.0 and ovs v2.17.0).
>
> I'm interested in validating a series of fixed issues on openvswitch and
> ovn in the releases related to the OpenStack Yoga version (e.g.
> https://github.com/ovn-org/ovn/commit/ccbbbd0584e52c2aa88436a431fe7a6deffd2221).
>
>
> What OpenStack automated testing tool do you use or recommend to validate
> the data plane?
>

I think you might get some answers if you post it in the relevant openinfra
neutron mailing lists.

Thanks
Numan

>
> Best regards
> Roberto
>
>
>
> *‘Esta mensagem é direcionada apenas para os endereços constantes no
> cabeçalho inicial. Se você não está listado nos endereços constantes no
> cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa
> mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão
> imediatamente anuladas e proibidas’.*
>
>  *‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para
> assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não
> poderá aceitar a responsabilidade por quaisquer perdas ou danos causados
> por esse e-mail ou por seus anexos’.*
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] How to install OpenvSwitch in userspace mode

[Numan Siddique]

On Tue, May 31, 2022 at 9:26 AM R.C. Thakur  wrote:
>
> Hi,
> I want to experiment with Openvswitch for my security related ideas.  I have 
> downloaded OpenvSwitch-2.11.7 and want to install it in userspace mode so 
> that I can do some changes in its internal functions and do communications 
> through multiple controllers.  I have gone through the document files 
> /Documentation/intro/install/general.rst and userspace .rst but confused how 
> to proceed further.
>
> Can anybody help me with its installation under ubuntu os.

Since you want to do some changes to openvswitch,  you should clone
the ovs repository from here - https://github.com/openvswitch/ovs.git
and follow the instructions from here -
https://github.com/openvswitch/ovs/blob/master/Documentation/intro/install/general.rst

Also openvswitch-2.11.7 is very old.  You should perhaps use the
latest released version or the master version.

Thanks
Numan

>
> Thanking you,
>
>
> R.C. Thakur
> Associate Professor
> NSUT, Dwarka, New Delhi-78
> Mobile:  9810998601, +918700017447
> Phone:  011-25000230(O), 011-2511(R)
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] I have a question about adding a new action in OVS.

[Numan Siddique]

On Wed, May 18, 2022 at 1:29 PM 胡兵  wrote:
>
> Hi,
> My name is Hu, and I want to add a new action in OVS.
> I need to add the datapath ID to each packet processed by the datapath,
> and save the previous datapath ids from the processed packet.
> And I also need the datapath to send the saved datapath IDs to the controller.
> Can someone give me some advice?
>
> I would really appreciate it if someone could give me some useful advice.


I'd suggest you to check out the FAQ here -
https://docs.openvswitch.org/en/latest/faq/contributing/

-
Q: How do I add support for a new OpenFlow action?

A: Add your new action to enum ofp_raw_action_type in
lib/ofp-actions.c, following the existing pattern. Then recompile and
fix all of the new warnings, implementing new functionality for the
new action as needed. (If you configure with --enable-Werror, as
described in the Open vSwitch on Linux, FreeBSD and NetBSD, then it is
impossible to miss any warnings.)

If you need to add an OpenFlow vendor extension action for a vendor
that doesn’t yet have any extension actions, then you will also need
to add the vendor to vendor_map in build-aux/extract-ofp-actions.
Also, you will need to add support for the vendor to
ofpact_decode_raw() and ofpact_put_raw() in lib/ofp-actions.c. (If you
have a choice of how to design your vendor extension actions, it will
be easier if you make them resemble the ONF and OVS extension
actions.)



Also if you're interested you can check this out -
https://dpdksummitbangalore2019.sched.com/event/LUEj/adding-a-new-ovs-action-numan-siddique-red-hat

https://www.youtube.com/watch?v=6uKnpha15xY

Thanks
Numan


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

Re: [ovs-discuss] Pacemaker and OVN

[Numan Siddique]

On Mon, May 16, 2022 at 5:46 PM Tiago Pires  wrote:

> Hi all,
>
> I'm following this documentation
> https://docs.ovn.org/en/latest/topics/integration.html and this thread
> https://www.mail-archive.com/ovs-discuss@openvswitch.org/msg05579.html in
> order to setup a Active-backup OVN cluster. (instead of Raft)
> The pacemaker cluster is ready and I'm having a trouble with the following:
>
> ## Add cluster resources [node01 --ONLY-- ]
> # pcs resource create ovn-virtual-ip ocf:heartbeat:IPaddr2 nic=lan1
> ip=192.168.0.10 cidr_netmask=32 op monitor interval=30s
>
> # pcs resource create ovndb_servers ocf:ovn:ovndb-servers \
> master_ip=192.168.0.10 \
> manage_northd="yes" \
> inactive_probe_interval=18 \
> ovn_ctl=/usr/share/ovn/scripts/ovn-ctl \
> op monitor interval="180s" \
> op monitor role=Master interval="200s"
>
> # pcs resource master ovndb_servers-master ovndb_servers meta notify="true"
> Error: This command has been replaced with 'pcs resource promotable'. See
> 'man pcs' -> Changes in pcs-0.10.
>
> I tried to use the:
>
> # pcs resource promotable ovndb_servers-master ovndb_servers meta
> notify="true"
> Error: unable to find group or resource: ovndb_servers-master
>
> Okay, it seems that something changed on the pacemaker side (the version
> I'm using is 2.0.3-3ubuntu4.3). But I did not figure out yet how to create
> the ovndb_servers-master as OVN's documentation says to follow the same.
> Has anyone had the same issue?
>

Adding Michele Baldessari (pacemaker expert) if he has any comments.

It's been a while since I've used pacemaker.  So I'm not sure  what changed.

If you're comfortable with puppet, probably you can refer to this -
https://github.com/openstack/puppet-tripleo/blob/master/manifests/profile/pacemaker/ovn_dbs_bundle.pp
Although the above creates a container bundle resource.

Numan


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

Re: [ovs-discuss] [ovn] TFTP server - next server missing?

[Numan Siddique]

On Fri, May 6, 2022, 5:57 AM Lucas Alvares Gomes 
wrote:

> Hi,
>
> On Fri, May 6, 2022 at 9:45 AM Daniel Alvarez Sanchez
>  wrote:
> >
> > Hi folks,
> >
> > While doing some tests with PXE booting and OVN, we noticed that even
> though the tftp-server option was sent by ovn-controller, the baremetal
> node wouldn't try to reach it to download the image. Comparing it to the
> output sent by dnsmasq, it looks like we're missing the next server option.
> >
> > After this 'hardcoded'  [0] (and dirty) patch, it seemed to work.
> >
>
> Thanks Daniel for describing the problem here.
>
> > Is this something we should add to OVN? For example, when the tftp-*
> options are set in the DHCP_Options table, have ovn-controller send the
> next-server address in the DHCP offer?
> >
>
> I would suggest doing it when the "tftp_server_address" option is set
> (DHCP 150), there's another option called "tftp_server" (DHCP 66) but
> that could also be the hostname of the machine. So using DHCP 150 is
> the way I would go about it.
>

This sounds reasonable to me.

Patch is welcome if you want to submit :)

Numan


> > Thanks!
> > daniel
> >
> > [0]
> >
> >
> > diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> > index ae3da332c..6c2c75a64 100644
> > --- a/controller/pinctrl.c
> > +++ b/controller/pinctrl.c
> > @@ -2259,6 +2259,7 @@ pinctrl_handle_put_dhcp_opts(
> >
> >  if (*in_dhcp_msg_type != OVN_DHCP_MSG_INFORM) {
> >  dhcp_data->yiaddr = (msg_type == DHCP_MSG_NAK) ? 0 : *offer_ip;
> > +dhcp_data->siaddr = (ovs_be32) inet_addr("172.27.7.29");
> >  } else {
> >  dhcp_data->yiaddr = 0;
> >  }
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Query wrt IPAM outside OVN

[Numan Siddique]

On Wed, Mar 2, 2022 at 2:44 PM Jaspal Singh Dhillon
 wrote:
>
> Hello again,
>
> Can you please assist with my query, to refresh:
>
> Is it possible for OVS/OVN to learn MAC-IP bindings in a network, where the 
> IPAM is done outside of OVN (basically external IPAM) ?
> We are exploring options to achieve it and one way is to snoop packets and 
> update CMS directly.
> But if this is a solved problem in OVS community, can you please suggest how 
> to go on about it.
>

OVN supports FDB learning provided the logical switch port has
addresses set to "unknown".   But it only stores the MAC-logical port
information
and not IP.  Please check  this -
https://github.com/ovn-org/ovn/blob/main/ovn-sb.ovsschema#L524  and
https://github.com/ovn-org/ovn/blob/main/ovn-sb.xml#L4511

To answer your question,  I don't think OVN supports MAC-IP learning
the way you are expecting.

We do have another table - MAC Binding in Southbound database, but
that is learnt in the router pipeline.

You can check that out here -
https://github.com/ovn-org/ovn/blob/main/ovn-sb.xml#L3365

Thanks
Numan

> Thanks,
> Jaspal
>
> 
> From: discuss  on behalf of Jaspal Singh 
> Dhillon 
> Sent: Wednesday, February 16, 2022 10:31 PM
> To: ovs-discuss@openvswitch.org 
> Cc: Avignan Chatterjee 
> Subject: [ovs-discuss] Query wrt IPAM outside OVN
>
> Hello,
>
> Is it possible for OVS/OVN to learn MAC-IP bindings in a network, where the 
> IPAM is done outside of OVN (basically external IPAM) ?
> We are exploring options to achieve it and one way is to snoop packets and 
> update CMS directly.
> But if this is a solved problem in OVS community, can you please suggest how 
> to go on about it.
>
> Thanks,
> Jaspal
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [External] : Re: reside-on-redirect-chassis and redirect-type

[Numan Siddique]

On Tue, Mar 1, 2022 at 6:31 AM Brendan Doyle  wrote:
>
>
>
> On 01/03/2022 01:12, Numan Siddique wrote:
> > On Mon, Feb 28, 2022 at 11:40 AM Brendan Doyle  
> > wrote:
> >>
> >>
> >> On 20/02/2022 23:38, Han Zhou wrote:
> >>
> >>
> >>
> >> On Thu, Feb 17, 2022 at 3:23 AM Brendan Doyle  
> >> wrote:
> >>> Hi,
> >>>
> >>> So I have a Distributed Gateway Port (DGP) on a Gateway through which
> >>> VMs in the overlay can access
> >>> underlay networks. If the VM is not on the chassis where the DGP is
> >>> scheduled then the traffic takes
> >>> the extra tunneled hop to the chassis where the DGP is and is then sent
> >>> to the underlay via the localnet
> >>> switch there.  It would be great if I could avoid that extra hop, whilst
> >>> still having the Gateway do NAT
> >>> and routing.  So I'm wondering if 'reside-on-redirect-chassis'  or '
> >>> redirect-type' can be used to
> >>> do this? and if so which one? Also will normal traffic between to VMs in
> >>> the overlay on different chassis
> >>> still be tunneled through the underlay?
> >>>
> >>> I'll do some experimentation later, but a nod in the right direction
> >>> would be appreciated.
> >>>
> >> Hi Brendan,
> >>
> >> Not sure if I understood your question well. If you want to avoid the 
> >> gateway hop, you can just configure NAT rules with "dnat_and_snat" to do 
> >> distributed NAT.
> >> 'reside-on-redirect-chassis' and 'redirect-type' don't seem to help for 
> >> your use case because you mentioned your VMs are in overlay, while those 
> >> options are for VLAN based logical networks.
> >>
> >>
> >> I must admit I found the ovn-nb/ovn-architetcure doc quite confusing on 
> >> this. I tracked down
> >> the patches and some ovn-discuss exchange and I think I understand it 
> >> better now. It
> >> seems that rather then avoiding the extra hop to the gateway chassis, 
> >> these redirect options
> >> just let you take that extra hop as a VLAN tagged packet in the underlay 
> >> rather than a geneve
> >> encapsulated packet. Which is not what I was hoping they would do. I'm not 
> >> sure what you mean
> >> by " you can just configure NAT rules with "dnat_and_snat" to do 
> >> distributed NAT" I could
> >> not find any reference to "distributed NAT" in the man pages. We use a 
> >> distributed router
> >> port Gateway for HA. Consider this config:
> >>
> >> switch 2ffbd2d8-5421-452a-b776-e32cc55f4789 (ls_vcn3)
> >>  port 269089c4-9464-41ec-9f63-6b3804b34b07
> >>  addresses: ["52:54:00:30:38:35 192.16.1.5"]
> >>  port ls_vcn3_net1-lr_vcn3_net1
> >>  type: router
> >>  addresses: ["40:44:00:00:00:90"]
> >>  router-port: lr_vcn3_net1-ls_vcn3_net1
> >>  port 284195d2-9280-4334-900e-571ecd00327a
> >>  addresses: ["52:54:00:02:55:96 192.16.1.6"]
> >>
> >> switch af0f96b0-d7af-41ef-b5b7-fa8ae0186c2c (ls_vcn3_backbone)
> >>  port lsb_vcn3-lr_vcn3
> >>  type: router
> >>  router-port: lr_vcn3-lsb_vcn3
> >>  port lsb_vcn3_net1-lr_vcn3_net1
> >>  type: router
> >>  router-port: lr_vcn3_net1-lsb_vcn3_net1
> >>
> >> switch 29bdf630-8326-4aa4-aee1-d9bca9ea298c (ls_vcn3_external_ugw)
> >>  port ls_vcn3_external_ugw-lr_vcn3
> >>  type: router
> >>  router-port: lr_vcn3-ls_vcn3_external_ugw
> >>  port ln-ls_vcn3_external_ugw
> >>  type: localnet
> >>  addresses: ["unknown"]
> >>
> >> router 638a1401-4e5f-450b-9d35-fe74defc8769 (lr_vcn3)
> >>  port lr_vcn3-ls_vcn3_external_ugw
> >>  mac: "40:44:00:00:01:60"
> >>  networks: ["253.255.80.4/16"]
> >>  gateway chassis: [sca15-rain17 sca15-rain05 sca15-rain06]
> >>  port lr_vcn3-lsb_vcn3
> >>  mac: "40:44:00:00:01:50"
> >>  networks: ["253.255.25.2/25"]
> >>  nat cb880ef9-d51c-4265-abdc-db6accaa4d4a
> >>  external ip: "253.255.80.4"
> >>  logical ip: "192.1

Re: [ovs-discuss] [External] : Re: reside-on-redirect-chassis and redirect-type

[Numan Siddique]

On Mon, Feb 28, 2022 at 11:40 AM Brendan Doyle  wrote:
>
>
>
> On 20/02/2022 23:38, Han Zhou wrote:
>
>
>
> On Thu, Feb 17, 2022 at 3:23 AM Brendan Doyle  
> wrote:
> >
> > Hi,
> >
> > So I have a Distributed Gateway Port (DGP) on a Gateway through which
> > VMs in the overlay can access
> > underlay networks. If the VM is not on the chassis where the DGP is
> > scheduled then the traffic takes
> > the extra tunneled hop to the chassis where the DGP is and is then sent
> > to the underlay via the localnet
> > switch there.  It would be great if I could avoid that extra hop, whilst
> > still having the Gateway do NAT
> > and routing.  So I'm wondering if 'reside-on-redirect-chassis'  or '
> > redirect-type' can be used to
> > do this? and if so which one? Also will normal traffic between to VMs in
> > the overlay on different chassis
> > still be tunneled through the underlay?
> >
> > I'll do some experimentation later, but a nod in the right direction
> > would be appreciated.
> >
> Hi Brendan,
>
> Not sure if I understood your question well. If you want to avoid the gateway 
> hop, you can just configure NAT rules with "dnat_and_snat" to do distributed 
> NAT.
> 'reside-on-redirect-chassis' and 'redirect-type' don't seem to help for your 
> use case because you mentioned your VMs are in overlay, while those options 
> are for VLAN based logical networks.
>
>
> I must admit I found the ovn-nb/ovn-architetcure doc quite confusing on this. 
> I tracked down
> the patches and some ovn-discuss exchange and I think I understand it better 
> now. It
> seems that rather then avoiding the extra hop to the gateway chassis, these 
> redirect options
> just let you take that extra hop as a VLAN tagged packet in the underlay 
> rather than a geneve
> encapsulated packet. Which is not what I was hoping they would do. I'm not 
> sure what you mean
> by " you can just configure NAT rules with "dnat_and_snat" to do distributed 
> NAT" I could
> not find any reference to "distributed NAT" in the man pages. We use a 
> distributed router
> port Gateway for HA. Consider this config:
>
> switch 2ffbd2d8-5421-452a-b776-e32cc55f4789 (ls_vcn3)
> port 269089c4-9464-41ec-9f63-6b3804b34b07
> addresses: ["52:54:00:30:38:35 192.16.1.5"]
> port ls_vcn3_net1-lr_vcn3_net1
> type: router
> addresses: ["40:44:00:00:00:90"]
> router-port: lr_vcn3_net1-ls_vcn3_net1
> port 284195d2-9280-4334-900e-571ecd00327a
> addresses: ["52:54:00:02:55:96 192.16.1.6"]
>
> switch af0f96b0-d7af-41ef-b5b7-fa8ae0186c2c (ls_vcn3_backbone)
> port lsb_vcn3-lr_vcn3
> type: router
> router-port: lr_vcn3-lsb_vcn3
> port lsb_vcn3_net1-lr_vcn3_net1
> type: router
> router-port: lr_vcn3_net1-lsb_vcn3_net1
>
> switch 29bdf630-8326-4aa4-aee1-d9bca9ea298c (ls_vcn3_external_ugw)
> port ls_vcn3_external_ugw-lr_vcn3
> type: router
> router-port: lr_vcn3-ls_vcn3_external_ugw
> port ln-ls_vcn3_external_ugw
> type: localnet
> addresses: ["unknown"]
>
> router 638a1401-4e5f-450b-9d35-fe74defc8769 (lr_vcn3)
> port lr_vcn3-ls_vcn3_external_ugw
> mac: "40:44:00:00:01:60"
> networks: ["253.255.80.4/16"]
> gateway chassis: [sca15-rain17 sca15-rain05 sca15-rain06]
> port lr_vcn3-lsb_vcn3
> mac: "40:44:00:00:01:50"
> networks: ["253.255.25.2/25"]
> nat cb880ef9-d51c-4265-abdc-db6accaa4d4a
> external ip: "253.255.80.4"
> logical ip: "192.16.0.0/16"
> type: "snat"
>
> router f370260a-c90c-4824-91a8-fba787272dc2 (lr_vcn3_net1)
> port lr_vcn3_net1-lsb_vcn3_net1
> mac: "40:44:00:00:00:a0"
> networks: ["253.255.25.1/25"]
> port lr_vcn3_net1-ls_vcn3_net1
> mac: "40:44:00:00:00:90"
> networks: ["192.16.1.1/24"]
>
> ovn-nbctl lr-nat-list lr_vcn3
> TYPE EXTERNAL_IPEXTERNAL_PORTLOGICAL_IP
> EXTERNAL_MAC LOGICAL_PORT
> snat 253.255.80.4192.16.0.0/16
>
> ovn-sbctl show
>
> Chassis sca15-rain05
> hostname: sca15-rain05
> Encap geneve
> ip: "253.255.2.5"
> options: {csum="true"}
> Port_Binding "269089c4-9464-41ec-9f63-6b3804b34b07"
> Port_Binding cr-lr_vcn3-ls_vcn3_external_ugw
>
> Chassis sca15-rain06
> hostname: sca15-rain06
> Encap geneve
> ip: "253.255.2.6"
> options: {csum="true"}
> Port_Binding "284195d2-9280-4334-900e-571ecd00327a"
>
>
> So if the overlay VM with IP 192.16.1.5  (hosted on chassis sca15-rain05) is 
> sending traffic to the
> underlay it will use "physical"/localnet bridge on  sca15-rain05. But if the 
> overlay VM with IP 192.16.1.6
> (hosted on chassis sca15-rain06) is sending traffic to the underlay, the 
> traffic is tunneled to sca15-rain05
> first, because that is where the DR port is, and then it is sent to the 
> underlay via the physical/localnet
> bridge there. It was that extra hop I wa

Re: [ovs-discuss] [ovs-dev] Datapath downtime during OVN upgrade

[Numan Siddique]

On Thu, Feb 3, 2022 at 5:22 PM Vladislav Odintsov  wrote:
>
> UPD2:
>
> I see that only snat/dnat ct zones are deleted and assigned again (link [1] 
> from previous mail).
> I’ve added more logging and see that local datapaths hmaps is empty on one 
> run and then snat/dnat zones are removed and on next run local_datapaths is 
> non-empty and snat/dnat ct-zones are assigned again with the same IDs.
> Lport zones are not touched but for some reason traffic between them 
> (lport-to-lport) is affected on ovn-controller start.
>

Thanks for the detailed investigation.

So it looks like we need to handle the ct zone assignment properly at
start up to avoid this disruption.

Numan

> Regards,
> Vladislav Odintsov
>
> > On 3 Feb 2022, at 19:56, Vladislav Odintsov  wrote:
> >
> > UPD:
> >
> > I’ve checked ovn-controller dbg logs and checked against its code.
> > Not sure, but looks like some bug in first processing of ct_zones. This 
> > logfile is from 20.06 version, but it has similar behaviour on v21.12:
> >
> > start ovn-controller
> >
> > 2022-02-03T16:09:50.500Z|00032|jsonrpc|DBG|unix:/run/openvswitch/db.sock: 
> > received reply, result={}, id=3
> > 2022-02-03T16:09:50.500Z|00033|ovsdb_idl|DBG|unix:/run/openvswitch/db.sock: 
> > received unexpected reply message: {"error":null,"id":3,"result":{}}
> > 2022-02-03T16:09:50.500Z|00034|main|DBG|restoring ct zone 25 for 
> > 'vnet37798-gateway-vif'
> > 2022-02-03T16:09:50.500Z|00035|main|DBG|restoring ct zone 8 for 
> > '5ae22181-33a5-4596-8143-e5e396fbc17e_dnat'
> > 2022-02-03T16:09:50.500Z|00036|main|DBG|restoring ct zone 57 for 
> > '3210cc4f-d055-4375-8425-aef0bd4db5fc_dnat'
> > 2022-02-03T16:09:50.500Z|00037|main|DBG|restoring ct zone 10 for 
> > 'vnet38045-gateway-vif'
> > 2022-02-03T16:09:50.500Z|00038|main|DBG|restoring ct zone 60 for 
> > '910c751a-3d86-420a-9606-3f751de4e8bf_dnat'
> > 2022-02-03T16:09:50.500Z|00039|main|DBG|restoring ct zone 146 for 
> > '30fda34a-7614-487a-9b17-258781c06e31_snat'
> > 2022-02-03T16:09:50.500Z|00040|main|DBG|restoring ct zone 171 for 
> > 'de72957f-b877-4c13-8b3d-9fe9b3abcc47_snat'
> > 2022-02-03T16:09:50.500Z|00041|main|DBG|restoring ct zone 184 for 
> > 'vnet36210-gateway-vif'
> > 2022-02-03T16:09:50.500Z|00042|main|DBG|restoring ct zone 120 for 
> > 'fdc23a91-fbcc-4fc4-9edd-e2001a827a2a_snat'
> > 2022-02-03T16:09:50.500Z|00043|main|DBG|restoring ct zone 102 for 
> > '2c9ea3e6-7ba1-445e-b707-1873d9a85e00_dnat'
> > 2022-02-03T16:09:50.500Z|00044|main|DBG|restoring ct zone 152 for 
> > 'fa746f3c-1d4e-450a-80c9-e6cd39676bbc_snat'
> > 2022-02-03T16:09:50.500Z|00045|main|DBG|restoring ct zone 92 for 
> > '8e81ebd1-f43d-4d90-85d9-dc9e85690f58_dnat'
> > 2022-02-03T16:09:50.500Z|00046|main|DBG|restoring ct zone 135 for 
> > 'ad815732-f341-4a6d-bdce-184dc6c53edf_snat'
> > 2022-02-03T16:09:50.500Z|00047|main|DBG|restoring ct zone 100 for 
> > 'vnet35091-gateway-vif'
> > 2022-02-03T16:09:50.500Z|00048|main|DBG|restoring ct zone 162 for 
> > '1078be52-1141-4060-b98d-23d96464b8bf_dnat'
> > 2022-02-03T16:09:50.500Z|00049|main|DBG|restoring ct zone 30 for 
> > '1078be52-1141-4060-b98d-23d96464b8bf_snat'
> > 2022-02-03T16:09:50.500Z|00050|main|DBG|restoring ct zone 130 for 
> > '605f08c3-f0be-4c0b-a721-5955bf2852d9_snat'
> > 2022-02-03T16:09:50.500Z|00051|main|DBG|restoring ct zone 121 for 
> > '27e28d02-ff81-4faa-b79b-8b6174e7ceea_dnat'
> > 2022-02-03T16:09:50.500Z|00052|main|DBG|restoring ct zone 70 for 
> > 'vnet35515-gateway-vif'
> > 2022-02-03T16:09:50.500Z|00053|main|DBG|restoring ct zone 26 for 
> > 'b56507c6-ac4b-4de0-b6d3-33936e98ad0b_dnat'
> > 2022-02-03T16:09:50.500Z|00054|main|DBG|restoring ct zone 114 for 
> > 'c7f1776b-0a1f-4434-bac5-db2b59f3363b_snat'
> > …
> > 2022-02-03T16:09:50.501Z|00226|inc_proc_eng|DBG|Initializing new run
> > …
> > 2022-02-03T16:09:50.730Z|00287|inc_proc_eng|DBG|Initializing new run
> > …
> > 2022-02-03T16:09:50.739Z|00311|inc_proc_eng|DBG|Initializing new run
> > 
> > …
> > 2022-02-03T16:09:50.754Z|00347|inc_proc_eng|DBG|Initializing new run
> > …
> > 2022-02-03T16:09:50.779Z|00408|main|DBG|removing ct zone 2 for 
> > '5601bacd-d246-42f8-aa69-c196f74ca57c_snat'
> > 2022-02-03T16:09:50.779Z|00409|main|DBG|removing ct zone 3 for 
> > '96b6fa7d-d974-4260-a58e-c78342fd097d_snat'
> > 2022-02-03T16:09:50.779Z|00410|main|DBG|removing ct zone 5 for 
> > 'a8e55770-885f-464e-bfa9-9c80eca0ce62_snat'
> > 2022-02-03T16:09:50.779Z|00411|main|DBG|removing ct zone 6 for 
> > '2969a6a5-012d-4504-83bf-be5192c4af87_dnat'
> > 2022-02-03T16:09:50.779Z|00412|main|DBG|removing ct zone 9 for 
> > '03175d56-14c2-4ea9-b671-e427fe6b62e6_dnat'
> > 2022-02-03T16:09:50.779Z|00413|main|DBG|removing ct zone 8 for 
> > '5ae22181-33a5-4596-8143-e5e396fbc17e_dnat'
> > 2022-02-03T16:09:50.779Z|00414|main|DBG|removing ct zone 12 for 
> > '11ecffe1-c6f9-4373-948a-fff26113af73_snat'
> > 2022-02-03T16:09:50.779Z|00415|main|DBG|removing ct zone 15 for 
> > '791f9a0b-81e4-4a9e-8f38-7d56332b6237_snat'
> > 2022-02-03T16:09:50.779Z|00416|

Re: [ovs-discuss] [External] : allow-related and allow-stateless not working when used together - should have the union of the rules.

[Numan Siddique]

On Fri, Jan 21, 2022 at 1:06 PM Brendan Doyle  wrote:
>
> Just wondering if there was any update on this?
>

I've not tested this scenario.  And I'm not too well versed with the
allow-stateless.
My guess here is that since you're mixing both stateful and stateless,
the packet is getting
dropped due to high priority flows which ovn-northd generates to drop
packets with ct.inv.

Can you verify if that is the case ?

When there are stateful ACLs,  you'd see logical flows like

-
  table=9 (ls_in_acl  ), priority=65532, match=(ct.inv ||
(ct.est && ct.rpl && ct_label.blocked == 1)), action=(drop;)
 ...
...
  table=4 (ls_out_acl ), priority=65532, match=(ct.inv ||
(ct.est && ct.rpl && ct_label.blocked == 1)), action=(drop;)

---


I'd suggest checking if these flows are hit in openflow table 17 or 44
on the compute node where the traffic is dropped.

I'm not sure if we support mixing both stateful and stateless.  I need
to check the code though,

Numan

>
> On 19/01/2022 10:47, Brendan Doyle wrote:
> > Hi,
> >
> > I have a simple network, two Subnets and VM in each with PortGroup
> > ACLs that
> > should allow ssh traffic from VM1 (192.16.1.6) in net1 to VM2
> > (192.16.2.5) in net2
> > as follows:
> >
> > net1 (192.16.1.0/24) vm1 --> ssh --> net2 (192.16.2.0/24) vm2
> >
> > However when I create these ACLs with a mix of stateful and stateless
> > rules
> > (It's a test case) then traffic is blocked AND no drop message is seen
> > in the
> > ovn-controller logs (have checked looking at the right logs this time)!
> >
> > Running tcpdump on the VMs I can see the pkt sent from VM1, being
> > received
> > by VM2, and the reply sent by VM2, but not received by VM1.
> >
> > North DB config:
> > 
> > switch 17a5ca86-2b1c-4610-9b2a-ea5be37b46a2 (ls1)
> > port net2-lr1
> > type: router
> > addresses: ["40:44:00:00:00:40"]
> > router-port: lr1-net2
> > port net1-lr1
> > type: router
> > addresses: ["40:44:00:00:00:30"]
> > router-port: lr1-net1
> > port 1cb7d760-90b0-4201-9517-88cb2de31c79
> > addresses: ["52:54:00:80:d0:c8 192.16.2.5"]
> > port 47433b54-ac10-42f1-ae84-cc6fbb580297
> > addresses: ["52:54:00:be:06:16 192.16.1.6"]
> >
> > router bb3ef25f-cfeb-4265-ae54-3872bc61972b (lr1)
> > port lr1-net1
> > mac: "40:44:00:00:00:30"
> > networks: ["192.16.1.1/24"]
> > port lr1-net2
> > mac: "40:44:00:00:00:40"
> > networks: ["192.16.2.1/24"]
> >
> > Port Groups with acls uuids removed for brevity
> > =
> >  ovn-nbctl list Port_Group
> > _uuid   : 3bb56a59-bcd2-486a-b86b-25b19f2bf6cf
> > name: pg2
> > ports   : [6d14a050-675f-4522-a013-19f701f82e39]
> >
> > _uuid   : 59fc542a-daab-449f-9e01-de6bee816770
> > name: pg1
> > ports   : [10f2ace1-a1bc-4e8e-9694-dbc3f91412a5]
> >
> > VM1 is in pg1 & VM2 is in pg2
> >
> > Now the ACLs which should allow VM1 to ssh to VM2
> > =
> > # ovn-nbctl acl-list pg1
> > from-lport 32767 (inport == @pg1 && (arp || udp.dst == 67 || udp.dst
> > == 68)) allow-related
> > from-lport 27000 (inport == @pg1 && ip.proto == 6 && (tcp.dst == 22))
> > allow-stateless
> > from-lport 0 (inport == @pg1) drop
> > log(name=net1_egress_drop,severity=debug)
> >   to-lport 32767 (outport == @pg1 && (arp || udp.dst == 67 || udp.dst
> > == 68)) allow-related
> >   to-lport 11000 (outport == @pg1 && ip.proto == 6 && (tcp.src == 22))
> > allow-related
> >   to-lport 0 (outport == @pg1) drop
> > log(name=net1_ingress_drop,severity=debug)
> >
> >
> > # ovn-nbctl acl-list pg2
> > from-lport 32767 (inport == @pg2 && (arp || udp.dst == 67 || udp.dst
> > == 68)) allow-related
> > from-lport 27000 (inport == @pg2 && ip.proto == 6 && (tcp.src == 22))
> > allow-stateless
> > from-lport 0 (inport == @pg2) drop
> > log(name=net2_egress_drop,severity=debug)
> >   to-lport 32767 (outport == @pg2 && (arp || udp.dst == 67 || udp.dst
> > == 68)) allow-related
> >   to-lport 11000 (outport == @pg2 && ip.proto == 6 && (tcp.dst == 22))
> > allow-related
> >   to-lport 0 (outport == @pg2) drop
> > log(name=net2_ingress_drop,severity=debug)
> >
> >
> > # ovn-controller --version
> > ovn-controller 21.12.90
> > Open vSwitch Library 2.16.90
> > OpenFlow versions 0x6:0x6
> > SB DB Schema 20.21.0
> >
> >
> > # git rev-parse HEAD
> > a906960af63118fe3bceb0a25c3ad2c85340b359
> >
> >
> >  cat /proc/version
> > Linux version 4.14.35-1902.8.4.el7uek.x86_64
> > (mockbuild@jenkins-10-147-72-125-e2b44982-16a5-48fe-95be-08a1e4c8f805)
> > (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16.0.3) (GCC)) #2 SMP Mon
> > Dec 9 11:39:31 PST 2019
> >
> >
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs

Re: [ovs-discuss] When will the videos and ppts of open vswitch and ovn 2021 fall conference be available

[Numan Siddique]

On Mon, Dec 20, 2021 at 7:55 PM David Zhang (张同剑)-浪潮信息
 wrote:
>
> Hi ：
>Do you know When will the videos and ppts of open vswitch and ovn 2021 
> fall conference be available? I'm sorry I didn't attend

Hi,

Day 1 videos are available here -
https://www.youtube.com/playlist?list=PLaJlRa-xItwARDGAUp7lXviOgOhcRxSU-

I'm not sure when day 2 videos will be available.

Thanks
Numan

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

Re: [ovs-discuss] 答复: 答复: What version of OVS supports compiling ovn21.09?

[Numan Siddique]

Hi,

Please check out -
https://mail.openvswitch.org/pipermail/ovs-dev/2021-December/389940.html

It has all the details to attend the conference.

Here's the registration link -
https://www.eventbrite.com/e/ovsovn-21-conference-registration-217640256867

Thanks
Numan

On Mon, Dec 6, 2021 at 9:15 PM David Zhang (张同剑)-浪潮信息
 wrote:
>
> Hi ：
>How can I attend themeeting：Open vSwitch and OVN 2021 Fall Conference
>http://www.openvswitch.org/support/ovscon2021/#T9
>Need ticket or resign  and  what is the meeting link？
>
> -----邮件原件-
> 发件人: Numan Siddique 
> 发送时间: 2021年12月2日, 星期四 22:27
> 收件人: David Zhang (张同剑)-浪潮信息 
> 抄送: syedam...@gmail.com; b...@openvswitch.org
> 主题: Re: [ovs-discuss] 答复: What version of OVS supports compiling ovn21.09?
>
> On Thu, Dec 2, 2021 at 12:55 AM David Zhang (张同剑)-浪潮信息
>  wrote:
> >
> > Hi;
> >
> > Tks, Get It.
> >
> >
> >
> > OVS submodule included in OVN 21.09 I can find from 
> > https://github.com/openvswitch/ovs/tree/1bdda7b6d53c92e877b457157676aff326414c53.
> >
> >
> >
> > For the version in the above link, from which file can I know the specific 
> > version of OVS?
>
>
> We normally include the OVS submodule commit from the OVS master branch.  So 
> the version would always be 2.16.90.
> >
> > And If I want to compile an ovn rpm, I need to specify the version number .
> >
> >
> >
> > In addition, how to compile the RPM of ovn?
>
>
> If you want to generate rpm from sources,  then first get inside the ovs 
> submodule directory, compile OVS and then do "make dist".
> And from the OVN directory  run "make rpm-fedora".
>
> You may have to install missing dependency packages required for rpm 
> generation.
>
> Thanks
> Numan
> >
> >
> >
> >
> >
> > 发件人: Numan Siddique 
> > 发送时间: 2021年12月2日, 星期四 11:45
> > 收件人: David Zhang (张同剑)-浪潮信息 
> > 抄送: syedam...@gmail.com; b...@openvswitch.org
> > 主题: Re: [ovs-discuss] What version of OVS supports compiling ovn21.09?
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Dec 1, 2021 at 10:22 PM David Zhang (张同剑)-浪潮信息 
> >  wrote:
> >
> > Hi:
> >
> >What version of OVS supports compiling ovn21.09?  I have tried
> > several versions of OVS release, such as 2.16. * 2.15.*,  but it will
> > be reported that OVS related functions cannot be found,
> >
> >
> >
> > Hi,
> >
> >
> >
> > For OVN 21.09 you need to use the OVS submodule included in ovn 21.09 which 
> > you can find here - https://github.com/ovn-org/ovn/tree/branch-21.09.
> >
> >
> >
> > After cloning ovn 21.09, run "git submodule update ovs".
> >
> >
> >
> > Please note that this version of OVS is only required for compiling OVN.  
> > You can use a different OVS version (2.15, 2.16  etc) at runtime.
> >
> >
> >
> > Numan
> >
> >
> >
> >
> >
> >
> >
> > T: 18801157293
> >
> >
> >
> > E: zhangt...@inspur.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Packet loss when using default security group with self reference

[Numan Siddique]

Hi,

If you're still seeing the packet loss issue in a production
environment, I suggest you to do the following
   - On the compute node where the packet loss is seen, save the ovs
flows in a file - "ovs-ofctl dump-flows br-int > before_recompute.txt"
   - then run the command - "ovn-appctl -t ovn-controller recompute"
   - Save the ovs flows again in a file and do a diff between them.
   - And see if you still see the packet issue.


Running the recompute command in a production cluster is fine.  As
this command triggers a full recomputation of OF flow generation and
installs any missing flows in ovs-vswitchd.

Thanks
Numan

On Fri, Dec 3, 2021 at 12:56 PM Christian Stelter
 wrote:
>
> Hi!
>
> First: we couldn't reproduce the problem on our stage env yet. We tried a mix 
> of Phoronix Test Suite, Ciscos TRex traffic simulator and the etcd setup. I'm 
> not sure how to share the 200 lines flow properly. I will try to send it as 
> an text file attachment. Hopefully it will not be stripped.
>
> So here is the default security group in the project with the etcd setup.
>
> --- cut ---
>   "rules": [
> {
>   "id": "047325dc-30a8-4257-a99f-a4829a9ef233",
>   "tenant_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa",
>   "security_group_id": "53ddbee9-d1f2-4586-b471-76b4923c4ec0",
>   "ethertype": "IPv6",
>   "direction": "egress",
>   "protocol": null,
>   "port_range_min": null,
>   "port_range_max": null,
>   "remote_ip_prefix": null,
>   "remote_group_id": null,
>   "description": null,
>   "tags": [],
>   "created_at": "2021-11-23T14:05:41Z",
>   "updated_at": "2021-11-23T14:05:41Z",
>   "revision_number": 0,
>   "project_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa"
> },
> {
>   "id": "05401a2a-8e0c-4a5a-b180-18708b4f013f",
>   "tenant_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa",
>   "security_group_id": "53ddbee9-d1f2-4586-b471-76b4923c4ec0",
>   "ethertype": "IPv4",
>   "direction": "egress",
>   "protocol": null,
>   "port_range_min": null,
>   "port_range_max": null,
>   "remote_ip_prefix": null,
>   "remote_group_id": null,
>   "description": null,
>   "tags": [],
>   "created_at": "2021-11-23T14:05:41Z",
>   "updated_at": "2021-11-23T14:05:41Z",
>   "revision_number": 0,
>   "project_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa"
> },
> {
>   "id": "1d7e67ac-0dfb-40f6-af40-c70964f06d85",
>   "tenant_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa",
>   "security_group_id": "53ddbee9-d1f2-4586-b471-76b4923c4ec0",
>   "ethertype": "IPv4",
>   "direction": "ingress",
>   "protocol": "icmp",
>   "port_range_min": null,
>   "port_range_max": null,
>   "remote_ip_prefix": "0.0.0.0/0",
>   "remote_group_id": null,
>   "description": "",
>   "tags": [],
>   "created_at": "2021-11-23T14:05:58Z",
>   "updated_at": "2021-11-23T14:05:58Z",
>   "revision_number": 0,
>   "project_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa"
> },
> {
>   "id": "35c132bc-5807-47a0-a700-3142897dc184",
>   "tenant_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa",
>   "security_group_id": "53ddbee9-d1f2-4586-b471-76b4923c4ec0",
>   "ethertype": "IPv6",
>   "direction": "ingress",
>   "protocol": null,
>   "port_range_min": null,
>   "port_range_max": null,
>   "remote_ip_prefix": null,
>   "remote_group_id": "53ddbee9-d1f2-4586-b471-76b4923c4ec0",
>   "description": null,
>   "tags": [],
>   "created_at": "2021-11-23T14:05:41Z",
>   "updated_at": "2021-11-23T14:05:41Z",
>   "revision_number": 0,
>   "project_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa"
> },
> {
>   "id": "582d622e-6990-4ea9-a36b-b67c79a55fd3",
>   "tenant_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa",
>   "security_group_id": "53ddbee9-d1f2-4586-b471-76b4923c4ec0",
>   "ethertype": "IPv4",
>   "direction": "ingress",
>   "protocol": "tcp",
>   "port_range_min": 22,
>   "port_range_max": 22,
>   "remote_ip_prefix": "0.0.0.0/0",
>   "remote_group_id": null,
>   "description": "",
>   "tags": [],
>   "created_at": "2021-11-23T14:05:55Z",
>   "updated_at": "2021-11-23T14:05:55Z",
>   "revision_number": 0,
>   "project_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa"
> },
> {
>   "id": "5b8ea15f-d9e5-4f55-a173-b9f6aae791fb",
>   "tenant_id": "fc1345e8baaf46aaba4a8c5a8b9f14fa",
>   "security_group_id": "53ddbee9-d1f2-4586-b471-76b4923c4ec0",
>   "ethertype": "IPv4",
>   "direction": "ingress",
>   "protocol": null,
>   "port_range_min": null,
>   "port_range_max": null,
>   "remote_ip_prefix": null,
>   "remote_group_id": "53ddbee9-d1f2-4586-b471-76b4923c4ec0",
>   "description": null,
>   "tags": [],
>   "created_at": "2021-11-23T14:05:41Z",
>   "updated_at": "2021-11-23T14:05:41Z",
>   "revision_number": 0,
>   "project_

Re: [ovs-discuss] 答复: What version of OVS supports compiling ovn21.09?

[Numan Siddique]

On Thu, Dec 2, 2021 at 12:55 AM David Zhang (张同剑)-浪潮信息
 wrote:
>
> Hi;
>
> Tks, Get It.
>
>
>
> OVS submodule included in OVN 21.09 I can find from 
> https://github.com/openvswitch/ovs/tree/1bdda7b6d53c92e877b457157676aff326414c53.
>
>
>
> For the version in the above link, from which file can I know the specific 
> version of OVS?


We normally include the OVS submodule commit from the OVS master
branch.  So the version would always be 2.16.90.
>
> And If I want to compile an ovn rpm, I need to specify the version number .
>
>
>
> In addition, how to compile the RPM of ovn?


If you want to generate rpm from sources,  then first get inside the
ovs submodule directory, compile OVS and then do "make dist".
And from the OVN directory  run "make rpm-fedora".

You may have to install missing dependency packages required for rpm generation.

Thanks
Numan
>
>
>
>
>
> 发件人: Numan Siddique 
> 发送时间: 2021年12月2日, 星期四 11:45
> 收件人: David Zhang (张同剑)-浪潮信息 
> 抄送: syedam...@gmail.com; b...@openvswitch.org
> 主题: Re: [ovs-discuss] What version of OVS supports compiling ovn21.09?
>
>
>
>
>
>
>
> On Wed, Dec 1, 2021 at 10:22 PM David Zhang (张同剑)-浪潮信息  
> wrote:
>
> Hi:
>
>What version of OVS supports compiling ovn21.09?  I have tried several 
> versions of OVS release, such as 2.16. * 2.15.*,  but it will be reported 
> that OVS related functions cannot be found,
>
>
>
> Hi,
>
>
>
> For OVN 21.09 you need to use the OVS submodule included in ovn 21.09 which 
> you can find here - https://github.com/ovn-org/ovn/tree/branch-21.09.
>
>
>
> After cloning ovn 21.09, run "git submodule update ovs".
>
>
>
> Please note that this version of OVS is only required for compiling OVN.  You 
> can use a different OVS version (2.15, 2.16  etc) at runtime.
>
>
>
> Numan
>
>
>
>
>
>
>
> T: 18801157293
>
>
>
> E: zhangt...@inspur.com
>
>
>
>
>
>
>
>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] What version of OVS supports compiling ovn21.09?

[Numan Siddique]

On Wed, Dec 1, 2021 at 10:22 PM David Zhang (张同剑)-浪潮信息 
wrote:

> Hi:
>
>What version of OVS supports compiling ovn21.09?  I have tried several
> versions of OVS release, such as 2.16. * 2.15.*,  but it will be reported
> that OVS related functions cannot be found,
>

Hi,

For OVN 21.09 you need to use the OVS submodule included in ovn 21.09 which
you can find here - https://github.com/ovn-org/ovn/tree/branch-21.09.

After cloning ovn 21.09, run "git submodule update ovs".

Please note that this version of OVS is only required for compiling OVN.
You can use a different OVS version (2.15, 2.16  etc) at runtime.

Numan



>
> *T:* 18801157293
>
>
>
> *E:* zhangt...@inspur.com
>
>
>
>
>
>
>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Packet loss when using default security group with self reference

[Numan Siddique]

On Tue, Nov 30, 2021 at 12:13 PM Daniel Alvarez  wrote:
>
> Hey Christian
>
> > On 30 Nov 2021, at 18:06, Christian Stelter  wrote:
> >
> > 
> > Hi!
> >
> > We’re observing currently packet loss on a 3 node etcd cluster (all 3 nodes 
> > on different hypervisors) on one of our open stack clusters running the 
> > victoria release deployed via kolla-ansible.
> >
> > Open vSwitch Library has version 2.13.3, the ovn-controller has version 
> > 20.03.2 and the underlaying OS is Ubuntu 20.04 with current patches.
> >
> > We can reproduce the packet loss with this etcd setup in different projects 
> > on that cluster, but not on a second cluster (our stage env) with the same 
> > software versions and the same hardware components and same sizing.
> >
> > When we replace the default security group with a security group that uses 
> > the CDIR of the project network as remote security group instead of 
> > “default” in the ingress rule (IP v4 Any Any) the etcd cluster performs 
> > without packet loss/recurring leader elections.
>
> I am confused as the default SG will block ingress traffic in OpenStack by 
> default.
>
> As this is an OVS/OVN ML, I would suggest to share the ACLs/Logical 
> Flows/OpenFlows for both cases. This question, framed like this requires 
> OpenStack (maybe even kolla-ansible if the default SG differs from the 
> reference implementation) and etcd knowledge so I would advise to isolate the 
> traffic pattern as much as possible as well as the packet loss % and other 
> potentially useful data.
>
>
> >
> > Other projects or applications seem not to be impacted. At least none that 
> > we know of.
> >
> > Any hints what could cause such a behavior? We suspect it's just a symptom 
> > of another problem that we are currently not aware of.
> >

In my opinion this could be due to an old bug in ovn-controller
related to wrong conjunction id generation.

Is it possible for you to test with the latest OVN version ?

If not can you run the below command and see if the packet loss issue
is resolved ?

Run - ovn-appctl -t ovn-controller recompute.

If running this command solves the issue, then it's definitely a known
issue which has been fixed in the later versions.  If you can confirm
this works
I can share the commit which fixed this issue.

Thanks
Numan

> > Kind regards,
> >
> > Christian Stelter
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [External] : Re: OVN using the wrong SNAT for established connections

[Numan Siddique]

On Thu, Nov 18, 2021 at 12:40 PM Brendan Doyle  wrote:
>
>
>
> On 18/11/2021 17:01, Numan Siddique wrote:
> > On Thu, Nov 18, 2021 at 10:46 AM Brendan Doyle  
> > wrote:
> >>
> >>
> >> On 08/11/2021 16:14, Numan Siddique wrote:
> >>> On Mon, Nov 8, 2021 at 5:39 AM Brendan Doyle  
> >>> wrote:
> >>>> Hi,
> >>>>
> >>>>
> >>>> So I have a Distributed router port gateway that had the following NAT 
> >>>> entry
> >>>>
> >>>>nat 2dbfe551-50ff-43f3-b8b0-7d2e857dea8c
> >>>>external ip: "253.255.80.24"
> >>>>logical ip: "10.117.0.0/23"
> >>>>type: "snat"
> >>>>
> >>>> A VM with IP 10.117.0.3 is using this to mount a filesystem in the
> >>>> underlay, all works fine
> >>>> it's 10.117.0.3 is SNAT'd to 253.255.80.24.
> >>>>
> >>>> Another NAT entry is added, so we have:
> >>>>
> >>>>nat 2dbfe551-50ff-43f3-b8b0-7d2e857dea8c
> >>>>external ip: "253.255.80.24"
> >>>>logical ip: "10.117.0.0/23"
> >>>>type: "snat"
> >>>>   nat 80572056-3bfd-4b10-abd0-4c084cd73474
> >>>>external ip: "253.255.80.30"
> >>>>logical ip: "10.117.0.0/24"
> >>>>type: "snat"
> >>>>
> >>>>
> >>>> I expect OVN to now SNAT 10.117.0.3 to 253.255.80.30 based on the
> >>>> longest prefix match.
> >>>> But it does not, it SNAT' to 253.255.80.24. If I umount the filesystems
> >>>> originally mounted when
> >>>> there was only the /23 SNAT entry. i.e the TCP connections are closed.
> >>>> Then I see OVN SNAT'ing
> >>>> to the correct IP with the longest prefix.
> >>>>
> >>>> It seems that the longest prefix match is not applied if there
> >>>> established TCP connections?
> >>>>
> >>>> What's the expected behavior here?
> >>> To me this seems to be the expected behavior with the present code.
> >>> Because since the connection was established already and since there
> >>> is a conntrack entry present for that connection,  the newly added flows
> >>> don't take effect.
> >>>
> >>> On the gateway node (or on the node where the NAT happens) if you
> >>> flush the conntrack entries, it would work as expected.
> >> So I'm assuming you mean with
> >>
> >> ovs-ofctl ct-flush-zone
> >>
> >> How would I find out what zone is associated with the NAT IP
> > On the gw node,  run - ovs-vsctl get bridge br-int external_ids
> >
> > You can see the snat zone and dnat zone ids allocated for the logical 
> > router.
> > The SB datapath_binding uuid for the logical router is used as the key.
>
> Thanks, so
>
>   ct-zone-ln-ls_vcn3_external_stgw="25",
>

This zone is for logical ports.

For SNAT/DNAT, router snat/dnat ids are used.

Eg. ct-zone-65b40bfa-9266-4ec7-826f-06cd99397427_dnat="4",
ct-zone-65b40bfa-9266-4ec7-826f-06cd99397427_snat="6"

Before flushing, you can run "conntrack -L  | grep "  just to
make sure that you see an entry for your old connection.

Thanks
Numan

> ovs-ofctl ct-flush-zone br-int 25

 For testing I normally run "conntrack -F" which flushes all the zones.
But I guess your approach to use ovs-ofctl ct-flush-zone is safer.

Numan

>
> >
> > Thanks
> > Numan
> >
> >> Brendan
> >>> Having said this,  I'm not sure what should be the ideal behaviour.
> >>>
> >>> Thanks
> >>> Numan
> >>>
> >>>> Brendan.
> >>>>
> >>>> ___
> >>>> discuss mailing list
> >>>> disc...@openvswitch.org
> >>>> https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!ZmCZlVEXQ1H-EANp8kVvFMa2SBzTAAJtqR5F3NXQnDc3HV0DVd90cLpqFe3RBKCsX_8$
> >> ___
> >> discuss mailing list
> >> disc...@openvswitch.org
> >> https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!ZJJyHZpS1-U1dPvEPVMZTChVVS-nkSERP7BuA7nMm4GmqWjGLrBpQZ8bjRWNpw3oTlo$
> >>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [External] : Re: OVN using the wrong SNAT for established connections

[Numan Siddique]

On Thu, Nov 18, 2021 at 10:46 AM Brendan Doyle  wrote:
>
>
>
> On 08/11/2021 16:14, Numan Siddique wrote:
> > On Mon, Nov 8, 2021 at 5:39 AM Brendan Doyle  
> > wrote:
> >> Hi,
> >>
> >>
> >> So I have a Distributed router port gateway that had the following NAT 
> >> entry
> >>
> >>   nat 2dbfe551-50ff-43f3-b8b0-7d2e857dea8c
> >>   external ip: "253.255.80.24"
> >>   logical ip: "10.117.0.0/23"
> >>   type: "snat"
> >>
> >> A VM with IP 10.117.0.3 is using this to mount a filesystem in the
> >> underlay, all works fine
> >> it's 10.117.0.3 is SNAT'd to 253.255.80.24.
> >>
> >> Another NAT entry is added, so we have:
> >>
> >>   nat 2dbfe551-50ff-43f3-b8b0-7d2e857dea8c
> >>   external ip: "253.255.80.24"
> >>   logical ip: "10.117.0.0/23"
> >>   type: "snat"
> >>  nat 80572056-3bfd-4b10-abd0-4c084cd73474
> >>   external ip: "253.255.80.30"
> >>   logical ip: "10.117.0.0/24"
> >>   type: "snat"
> >>
> >>
> >> I expect OVN to now SNAT 10.117.0.3 to 253.255.80.30 based on the
> >> longest prefix match.
> >> But it does not, it SNAT' to 253.255.80.24. If I umount the filesystems
> >> originally mounted when
> >> there was only the /23 SNAT entry. i.e the TCP connections are closed.
> >> Then I see OVN SNAT'ing
> >> to the correct IP with the longest prefix.
> >>
> >> It seems that the longest prefix match is not applied if there
> >> established TCP connections?
> >>
> >> What's the expected behavior here?
> > To me this seems to be the expected behavior with the present code.
> > Because since the connection was established already and since there
> > is a conntrack entry present for that connection,  the newly added flows
> > don't take effect.
> >
> > On the gateway node (or on the node where the NAT happens) if you
> > flush the conntrack entries, it would work as expected.
> So I'm assuming you mean with
>
> ovs-ofctl ct-flush-zone
>
> How would I find out what zone is associated with the NAT IP

On the gw node,  run - ovs-vsctl get bridge br-int external_ids

You can see the snat zone and dnat zone ids allocated for the logical router.
The SB datapath_binding uuid for the logical router is used as the key.

Thanks
Numan

>
> Brendan
> > Having said this,  I'm not sure what should be the ideal behaviour.
> >
> > Thanks
> > Numan
> >
> >> Brendan.
> >>
> >> ___
> >> discuss mailing list
> >> disc...@openvswitch.org
> >> https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!ZmCZlVEXQ1H-EANp8kVvFMa2SBzTAAJtqR5F3NXQnDc3HV0DVd90cLpqFe3RBKCsX_8$
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN using the wrong SNAT for established connections

[Numan Siddique]

On Mon, Nov 8, 2021 at 5:39 AM Brendan Doyle  wrote:
>
> Hi,
>
>
> So I have a Distributed router port gateway that had the following NAT entry
>
>  nat 2dbfe551-50ff-43f3-b8b0-7d2e857dea8c
>  external ip: "253.255.80.24"
>  logical ip: "10.117.0.0/23"
>  type: "snat"
>
> A VM with IP 10.117.0.3 is using this to mount a filesystem in the
> underlay, all works fine
> it's 10.117.0.3 is SNAT'd to 253.255.80.24.
>
> Another NAT entry is added, so we have:
>
>  nat 2dbfe551-50ff-43f3-b8b0-7d2e857dea8c
>  external ip: "253.255.80.24"
>  logical ip: "10.117.0.0/23"
>  type: "snat"
> nat 80572056-3bfd-4b10-abd0-4c084cd73474
>  external ip: "253.255.80.30"
>  logical ip: "10.117.0.0/24"
>  type: "snat"
>
>
> I expect OVN to now SNAT 10.117.0.3 to 253.255.80.30 based on the
> longest prefix match.
> But it does not, it SNAT' to 253.255.80.24. If I umount the filesystems
> originally mounted when
> there was only the /23 SNAT entry. i.e the TCP connections are closed.
> Then I see OVN SNAT'ing
> to the correct IP with the longest prefix.
>
> It seems that the longest prefix match is not applied if there
> established TCP connections?
>
> What's the expected behavior here?

To me this seems to be the expected behavior with the present code.
Because since the connection was established already and since there
is a conntrack entry present for that connection,  the newly added flows
don't take effect.

On the gateway node (or on the node where the NAT happens) if you
flush the conntrack entries, it would work as expected.

Having said this,  I'm not sure what should be the ideal behaviour.

Thanks
Numan

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

Re: [ovs-discuss] [ovn] Upgrade from 20.12 to 21.09

[Numan Siddique]

On Wed, Nov 3, 2021 at 2:02 AM Ammad Syed  wrote:
>
> Hi,
>
> I have upgraded ovn controllers on compute nodes and ovn central on network 
> node.
>
> The package has been upgraded and everything works fine.
>
> How to check to check ovnsb and ovnnb databases has upgraded successfully ?
>
> I am seeing ovnnb version in ovnnb_db.db 
> "name":"OVN_Northbound","version":"5.32.1"
> and for ovnsb version in ovnsb_db.db 
> "name":"OVN_Southbound","version":"20.20.0" in the start of the db file.
>
> I can also see below db files created after upgrade.
>
> -rw-r- 1 root root 151488 Nov  2 14:23 ovnnb_db.db
> -rw-r- 1 root root  78946 Nov  2 10:34 ovnnb_db.db.backup5.28.0-610359755
> -rw-r- 1 root root 969484 Nov  2 14:23 ovnsb_db.db
> -rw-r- 1 root root 391183 Nov  2 10:34 
> ovnsb_db.db.backup20.12.0-3969471120
>
> How to ensure that db upgrade has been performed successfully ?

If the dbs didn't upgrade properly,  then you should see warning
messages like "Missing tables/columns"
in the ovn-northd/ovn-controller log files.

The NB version - 5.32.1  you mentioned matches here -
https://github.com/ovn-org/ovn/blob/v21.09.0/ovn-nb.ovsschema

So I think it went well.

Thanks
Numan

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

Re: [ovs-discuss] [External] : Re: /etc/openvswitch/conf.db filling up with lost of "ovn-controller: modifying OVS tunnels" updates

[Numan Siddique]

On Thu, Oct 28, 2021 at 12:21 PM Brendan Doyle  wrote:
>
>
> I'm also hoping that this is the reason for the frequent SEGV's we see,
> this a stacktrace that looks like:
>
> Core was generated by `ovs-vswitchd unix:/var/run/openvswitch/db.sock
> -vconsole:emer -vsyslog:err -vfi'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7f69b4477e84 in classifier_lookup__ (cls=0x55edff13e8b8,
>  version=version@entry=72104, flow=flow@entry=0x7f699abb2490,
>  wc=wc@entry=0x7f699abd4730,
>  allow_conjunctive_matches=allow_conjunctive_matches@entry=true)
>  at lib/classifier.c:941
>
> Full trace attached (almost 8000 frames deep!) when ovs-vswitchd SEGV's
> like this systemd
> can't restart it, as the the DB file is too large:

IMO ovs-vswitchd should not crash if the ovn-controller does something wrong.
Seems like a  bug in vswitchd.

Thanks
Numan
>
>   ls -lh /etc/openvswitch/conf.db
> -rw-r--r--. 1 root root 4.2G Oct 28 11:25 /etc/openvswitch/conf.db
>
> It just times out.
>
> Anyways we'll try the pactch and hopefully that will solve the problem.
>
>
> On 28/10/2021 16:41, Numan Siddique wrote:
> > On Thu, Oct 28, 2021 at 5:20 AM Brendan Doyle  
> > wrote:
> >> Numan,
> >>
> >> Just wondering if you got  a chance to look at those logs?
> > I looked into the logs,  and as I had mentioned earlier you need this
> > fix - 
> > https://urldefense.com/v3/__https://github.com/ovn-org/ovn/commit/e7788554a7f5e824fc0d8afc6cbf20e94fe4245f__;!!ACWV5N9M2RV99hQ!amdtq3tQhwFCtbvjxSuF5ItzNk_07I0bBJvt5mu3lbJc-NBU5rsCp9IIullXTrxBXf8$
> >
> > Please let me know if you still see this issue with the latest OVN or
> > with the version of OVN which has this fix.
> > This fix is available from OVN 21.03 and onwards.
> >
> > Thanks
> > Numan
> >
> >> Thanks
> >>
> >> Brendan
> >>
> >> On 27/10/2021 11:25, Brendan Doyle wrote:
> >>
> >> Hi,
> >>
> >> I finally got some debug logs, truncated after the failure occurs, the 
> >> truncated entries just
> >> are repeated updates of the same entry.
> >>
> >> So some more light on this, It seems this is a timing issue. The test 
> >> being run involves
> >> creating  a number of Logical switches (LS), Routers (LR) and Distributed 
> >> Router Port
> >> gateways (DR). And then immediately deleting them, with the last created 
> >> DR being
> >> deleted first. Our CMs is using the ovsdbapp python lib to do this.
> >>
> >> So it occurs to me that perhaps the objects get created in NB, but before 
> >> they have been
> >> propagated to SB and to the HV chassis, we get the delete, and this causes 
> >> updates to
> >> be sent to the chassis for a logical port that does not exist? Just a 
> >> hypothesis.
> >>
> >> The ovn-nbctl has synchronization flags (--wait) to guard against such 
> >> behavior, does
> >> ovsdbapp I wonder?
> >>
> >> In any-case the test fails (we see a runaway conf.db) pretty regularly, 
> >> but not every time.
> >> The failure is always observed on the delete operations. If I put a delay 
> >> after create and
> >> before delete, then we don't see the failure.
> >>
> >> If anyone can shed light on this from the logs would be much appreciated.
> >>
> >> Thanks
> >>
> >> Brendan
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 26/10/2021 17:11, Brendan Doyle wrote:
> >>
> >>
> >>
> >> On 26/10/2021 15:50, Numan Siddique wrote:
> >>
> >> On Tue, Oct 26, 2021 at 8:20 AM Brendan Doyle  
> >> wrote:
> >>
> >> Hi,
> >>
> >>
> >> So what is very odd here, is that I have used ovn-nbctl to delete the NB
> >> config, so
> >> # ovn-nbctl show
> >> # ovn-sbctl lflow-list
> >>
> >> Yet I still see /etc/openvswitch/conf.db growing with updates for
> >> Logical switch ports that no longer exist!
> >>
> >> "],["ct-zone-ln-ls_vcn9195577_external_ugw","220"],["ct-zone-ln-ls_vcn9206002_external_igw","110"],["ct-zone-ln-ls_vcn9210052_external_igw","110"],["ct-zone-ln-ls_vcn9232395_external_ugw","75"],["ct-zone-ln-ls_vcn9236987_external_igw","110"],["ct-zone-ln-ls_vcn9236987_external_ugw","78&q

Re: [ovs-discuss] Regarding ovsdb replication model

[Numan Siddique]

On Thu, Oct 28, 2021 at 7:30 AM Rutuja Umesh Madhure
 wrote:
>
> Hi,
>
> In the ovsdb replication model, is there a way to know/check whether the 
> replica is up-to-date with the master/active server.

I don't think there is a way to know that.  When the active
ovsdb-server commits a transaction it sends out
the update to the replica ovsdb-servers.

> Also, when we want to set a new active server for the replica, does the below 
> command wait for the replica to be up-to-date with the old master.

No. I don't think it would wait.

Thanks
Numan

>
> ovsdb-server/set-active-ovsdb-server server
>
>
> Thanks and regards,
> Rutuja Madhure
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [External] : Re: /etc/openvswitch/conf.db filling up with lost of "ovn-controller: modifying OVS tunnels" updates

[Numan Siddique]

On Thu, Oct 28, 2021 at 5:20 AM Brendan Doyle  wrote:
>
> Numan,
>
> Just wondering if you got  a chance to look at those logs?

I looked into the logs,  and as I had mentioned earlier you need this
fix - 
https://github.com/ovn-org/ovn/commit/e7788554a7f5e824fc0d8afc6cbf20e94fe4245f

Please let me know if you still see this issue with the latest OVN or
with the version of OVN which has this fix.
This fix is available from OVN 21.03 and onwards.

Thanks
Numan

>
> Thanks
>
> Brendan
>
> On 27/10/2021 11:25, Brendan Doyle wrote:
>
> Hi,
>
> I finally got some debug logs, truncated after the failure occurs, the 
> truncated entries just
> are repeated updates of the same entry.
>
> So some more light on this, It seems this is a timing issue. The test being 
> run involves
> creating  a number of Logical switches (LS), Routers (LR) and Distributed 
> Router Port
> gateways (DR). And then immediately deleting them, with the last created DR 
> being
> deleted first. Our CMs is using the ovsdbapp python lib to do this.
>
> So it occurs to me that perhaps the objects get created in NB, but before 
> they have been
> propagated to SB and to the HV chassis, we get the delete, and this causes 
> updates to
> be sent to the chassis for a logical port that does not exist? Just a 
> hypothesis.
>
> The ovn-nbctl has synchronization flags (--wait) to guard against such 
> behavior, does
> ovsdbapp I wonder?
>
> In any-case the test fails (we see a runaway conf.db) pretty regularly, but 
> not every time.
> The failure is always observed on the delete operations. If I put a delay 
> after create and
> before delete, then we don't see the failure.
>
> If anyone can shed light on this from the logs would be much appreciated.
>
> Thanks
>
> Brendan
>
>
>
>
>
>
>
> On 26/10/2021 17:11, Brendan Doyle wrote:
>
>
>
> On 26/10/2021 15:50, Numan Siddique wrote:
>
> On Tue, Oct 26, 2021 at 8:20 AM Brendan Doyle  
> wrote:
>
> Hi,
>
>
> So what is very odd here, is that I have used ovn-nbctl to delete the NB
> config, so
> # ovn-nbctl show
> # ovn-sbctl lflow-list
>
> Yet I still see /etc/openvswitch/conf.db growing with updates for
> Logical switch ports that no longer exist!
>
> "],["ct-zone-ln-ls_vcn9195577_external_ugw","220"],["ct-zone-ln-ls_vcn9206002_external_igw","110"],["ct-zone-ln-ls_vcn9210052_external_igw","110"],["ct-zone-ln-ls_vcn9232395_external_ugw","75"],["ct-zone-ln-ls_vcn9236987_external_igw","110"],["ct-zone-ln-ls_vcn9236987_external_ugw","78"],["ct-zone-ln-ls_vcn9255861_external_igw","118"],["ct-zone-ln-ls_vcn9255861_external_ugw","100"],["ct-zone-ln-ls_vcn9319435_external_igw","87"],["ct-zone-ln-ls_vcn9352502_external_igw","40"],["ct-zone-ln-ls_vcn9402504_external_ugw","99"],["ct-zone-ln-ls_vcn9403404_external_igw","133"],["ct-zone-ln-ls_vcn9403404_external_ugw","114"],["ct-zone-ln-ls_vcn9461566_external_ugw","191"],["ct-zone-ln-ls_vcn948_external_igw","254"],["ct-zone-ln-ls_vcn948_external_ugw","236"],["ct-zone-ln-ls_vcn9492134_external_igw","262"],["ct-zone-ln-ls_vcn9523503_external_igw","207"],["ct-zone-ln-ls_vcn9542102_external_igw","133"],["ct-zone-ln-ls_vcn9542102_external_ugw","115"],["ct-zone-ln-ls_vcn9559658_external_ig
 
w","125"],["ct-zone-ln-ls_vcn9559658_external_ugw","78"],["ct-zone-ln-ls_vcn9594034_external_igw","49"],["ct-zone-ln-ls_vcn9619021_external_igw","133"],["ct-zone-ln-ls_vcn9634773_external_igw","292"],["ct-zone-ln-ls_vcn9649169_external_igw","132"],["ct-zone-ln-ls_vcn9649169_external_ugw","110"],["ct-zone-ln-ls_vcn9661290_external_ugw","78"],["ct-zone-ln-ls_vcn9734192_external_ugw","114"],["ct-zone-ln-ls_vcn9774252_external_igw","262"],["ct-zone-ln-ls_vcn9796262_external_igw","72"],["ct-zone-ln-ls_vcn9796262_external_ugw","54"],["ct-zone-ln-ls_vcn9805903_external_igw","147"],["ct-zone-ln-ls_vcn9805903_external_ugw","126"],["ct-zone-ln-ls_vcn9809895_external_igw","246"],["ct-zone-ln-ls_vcn9812576_external_ugw","78"],["ct-zone-ln-ls_vcn9834728_external_igw","110"],["ct-zone-ln-ls_vcn9886683_external_ugw",&q

Re: [ovs-discuss] [External] : Re: /etc/openvswitch/conf.db filling up with lost of "ovn-controller: modifying OVS tunnels" updates

[Numan Siddique]

On Tue, Oct 26, 2021 at 8:20 AM Brendan Doyle  wrote:
>
> Hi,
>
>
> So what is very odd here, is that I have used ovn-nbctl to delete the NB
> config, so
> # ovn-nbctl show
> # ovn-sbctl lflow-list
>
> Yet I still see /etc/openvswitch/conf.db growing with updates for
> Logical switch ports that no longer exist!
>
> "],["ct-zone-ln-ls_vcn9195577_external_ugw","220"],["ct-zone-ln-ls_vcn9206002_external_igw","110"],["ct-zone-ln-ls_vcn9210052_external_igw","110"],["ct-zone-ln-ls_vcn9232395_external_ugw","75"],["ct-zone-ln-ls_vcn9236987_external_igw","110"],["ct-zone-ln-ls_vcn9236987_external_ugw","78"],["ct-zone-ln-ls_vcn9255861_external_igw","118"],["ct-zone-ln-ls_vcn9255861_external_ugw","100"],["ct-zone-ln-ls_vcn9319435_external_igw","87"],["ct-zone-ln-ls_vcn9352502_external_igw","40"],["ct-zone-ln-ls_vcn9402504_external_ugw","99"],["ct-zone-ln-ls_vcn9403404_external_igw","133"],["ct-zone-ln-ls_vcn9403404_external_ugw","114"],["ct-zone-ln-ls_vcn9461566_external_ugw","191"],["ct-zone-ln-ls_vcn948_external_igw","254"],["ct-zone-ln-ls_vcn948_external_ugw","236"],["ct-zone-ln-ls_vcn9492134_external_igw","262"],["ct-zone-ln-ls_vcn9523503_external_igw","207"],["ct-zone-ln-ls_vcn9542102_external_igw","133"],["ct-zone-ln-ls_vcn9542102_external_ugw","115"],["ct-zone-ln-ls_vcn9559658_external_ig
 
w","125"],["ct-zone-ln-ls_vcn9559658_external_ugw","78"],["ct-zone-ln-ls_vcn9594034_external_igw","49"],["ct-zone-ln-ls_vcn9619021_external_igw","133"],["ct-zone-ln-ls_vcn9634773_external_igw","292"],["ct-zone-ln-ls_vcn9649169_external_igw","132"],["ct-zone-ln-ls_vcn9649169_external_ugw","110"],["ct-zone-ln-ls_vcn9661290_external_ugw","78"],["ct-zone-ln-ls_vcn9734192_external_ugw","114"],["ct-zone-ln-ls_vcn9774252_external_igw","262"],["ct-zone-ln-ls_vcn9796262_external_igw","72"],["ct-zone-ln-ls_vcn9796262_external_ugw","54"],["ct-zone-ln-ls_vcn9805903_external_igw","147"],["ct-zone-ln-ls_vcn9805903_external_ugw","126"],["ct-zone-ln-ls_vcn9809895_external_igw","246"],["ct-zone-ln-ls_vcn9812576_external_ugw","78"],["ct-zone-ln-ls_vcn9834728_external_igw","110"],["ct-zone-ln-ls_vcn9886683_external_ugw","114"],["ct-zone-ln-ls_vcn9903419_external_ugw","235"],["ct-zone-ln-ls_vcn9917510_external_igw","56"],["ct-zone-ln-ls_vcn9917510_external_ugw","38"]]]}},"_comment":"ovn-controller:
> modifying OVS tunnels 'pcacn001'"}
>
> A shortened version of one entry Could it be that switch ports must be
> deleted before
> deleting the switch? I was under the impression once a switch is deleted
> it's ports get deleted?

Yes.  If you delete the switch,  the switch ports get deleted too.

After deleting the logical switch (or switch ports) do you see them to
be deleted by
ovn-northd in SB DB ?

Run - ovn-sbctl list port_binding 
or/and

ovn-sbctl list datapath_binding 

I'd suggest you enable jsonrpc debug in ovn-controller and see what's happening.
It would be helpful if you can share the ovn-controller debug logs.

ovn-appctl -t ovn-controller vlog/set jsonrpc:dbg


Thanks
Numan

>
>
> switch 712757c3-2481-4f8b-940c-05dc13ce37a5 (ls_vcn9319435_external_ugw)
>  port ls_vcn9319435_external_ugw-lr_vcn9319435
>  type: router
>  router-port: lr_vcn9319435-ls_vcn9319435_external_ugw
>  port ln-ls_vcn9319435_external_ugw
>  type: localnet
>  addresses: ["unknown"]
>
> router 80c281af-319b-416b-8a17-0ce7b8901bb1 (lr_vcn9319435)
>  port lr_vcn9319435-ls_vcn9319435_external_ugw
>  mac: "00:13:97:88:31:90"
>  networks: ["253.255.80.4/16"]
>  gateway chassis: [pcacn002 pcacn003 pcacn001]
>  port lr_vcn9319435-lsb_vcn9319435
>  mac: "00:13:97:d4:26:ec"
>  networks: ["253.255.29.2/25"]
>  nat 6c87050f-cd27-423e-815e-deda74bd9bc6
>  external ip: "253.255.80.4"
>  logical ip: "10.221.0.0/16"
>  type: "snat"
>
> Do each port have to be deleted or is it ok to just delete the 

Re: [ovs-discuss] /etc/openvswitch/conf.db filling up with lost of "ovn-controller: modifying OVS tunnels" updates

[Numan Siddique]

On Fri, Oct 22, 2021 at 9:30 AM Brendan Doyle  wrote:
>
> Hi,
>
>
> Looking at /etc/openvswitch/conf.db I see it getting very large:
>
> [root@pcacn001 ~]#  ls -l /etc/openvswitch/conf.db
> -rw-r--r--. 1 root root 6069248828 Oct 22 11:55 /etc/openvswitch/conf.db
>
> And has lots and lots (mostly)  "ovn-controller: modifying OVS tunnels"
> updates entries, like below.
> What are these? it does not seem normal?
> OVSDB JSON 4687 00e8788dd5d9af2aac5ca7724759017c52ddd580
> {"_date":1634903752117,"Bridge":{"745726c4-0451-4f52-a52b-1f9c5e85c703":{"external_ids":["map",[["ct-zone-0dca7370-1c18-4117-84e4-a72f277ccc6c_dnat","4"],["ct-zone-0dca7370-1c18-4117-84e4-a72f277ccc6c_snat","1"],["ct-zone-11637f38-8725-4c77-adfe-f9c4c804ae8c_dnat","4"],["ct-zone-11637f38-8725-4c77-adfe-f9c4c804ae8c_snat","5"],["ct-zone-1de487d1-f3a5-4b15-bae4-aa8cf794fcf9_dnat","17"],["ct-zone-1de487d1-f3a5-4b15-bae4-aa8cf794fcf9_snat","7"],["ct-zone-22c71c2a-0e59-41cc-a2da-91d3c7276c11_dnat","9"],["ct-zone-22c71c2a-0e59-41cc-a2da-91d3c7276c11_snat","10"],["ct-zone-3228b120-4192-476b-ab67-51fb45e786d6_dnat","3"],["ct-zone-3228b120-4192-476b-ab67-51fb45e786d6_snat","4"],["ct-zone-3753ff1a-d0cf-48e4-b06a-640f0467d202_dnat","19"],["ct-zone-3753ff1a-d0cf-48e4-b06a-640f0467d202_snat","18"],["ct-zone-3c1c02f4-31c9-45d4-9c63-54ad2122bb15_dnat","10"],["ct-zone-3c1c02f4-31c9-45d4-9c63-54ad2122bb15_snat","16"],["ct-zone-423896cb-5573-4c54-b6e2-38f192eacae3_dnat","9"],["ct-zone-423896cb-5573-
 
4c54-b6e2-38f192eacae3_snat","12"],["ct-zone-46b7b247-31a7-4fbb-88b9-0f3db042409c_dnat","10"],["ct-zone-46b7b247-31a7-4fbb-88b9-0f3db042409c_snat","11"],["ct-zone-51376927-fca0-49b3-b0ba-1aa22153b366_dnat","2"],["ct-zone-51376927-fca0-49b3-b0ba-1aa22153b366_snat","5"],["ct-zone-58033baa-916d-47d4-bcf0-d95f7fb1f861_dnat","18"],["ct-zone-58033baa-916d-47d4-bcf0-d95f7fb1f861_snat","3"],["ct-zone-5f92f974-f0dc-4820-bb43-a14cc16d851f_dnat","12"],["ct-zone-5f92f974-f0dc-4820-bb43-a14cc16d851f_snat","11"],["ct-zone-87055326-0535-4042-a0ff-bf0e9f494433_dnat","10"],["ct-zone-87055326-0535-4042-a0ff-bf0e9f494433_snat","12"],["ct-zone-8a840bfe-118f-4041-ac72-0637d6373ffc_dnat","1"],["ct-zone-8a840bfe-118f-4041-ac72-0637d6373ffc_snat","11"],["ct-zone-8fff9b0b-0fd6-42f9-ab77-e9f1475a5d82_dnat","2"],["ct-zone-8fff9b0b-0fd6-42f9-ab77-e9f1475a5d82_snat","13"],["ct-zone-913c36a1-f987-4084-9119-f279b317c72f_dnat","11"],["ct-zone-913c36a1-f987-4084-9119-f279b317c72f_snat","12"],["ct-zone-9498aca9-7623
 
-4ce0-a0ff-d4d5c17d7223_dnat","19"],["ct-zone-9498aca9-7623-4ce0-a0ff-d4d5c17d7223_snat","15"],["ct-zone-9c373522-fd02-424f-a2b3-14dc359062d2_dnat","18"],["ct-zone-9c373522-fd02-424f-a2b3-14dc359062d2_snat","17"],["ct-zone-a28b45db-2dfb-4d38-905c-c5eb44da8c9c_dnat","13"],["ct-zone-a28b45db-2dfb-4d38-905c-c5eb44da8c9c_snat","10"],["ct-zone-b1e8636a-5cf8-48ba-9693-793a59e5430d_dnat","8"],["ct-zone-b1e8636a-5cf8-48ba-9693-793a59e5430d_snat","14"],["ct-zone-bbcc6e17-ee1e-4e82-b404-1dd0f1307002_dnat","12"],["ct-zone-bbcc6e17-ee1e-4e82-b404-1dd0f1307002_snat","11"],["ct-zone-bd3b86b7-2aba-4ff7-a5f7-975612692aca_dnat","13"],["ct-zone-bd3b86b7-2aba-4ff7-a5f7-975612692aca_snat","10"],["ct-zone-cb94affd-f2aa-4bdd-9407-1e16ac046596_dnat","9"],["ct-zone-cb94affd-f2aa-4bdd-9407-1e16ac046596_snat","1"],["ct-zone-ce71f6db-4dab-41ca-bd10-cd6204687b9d_dnat","16"],["ct-zone-ce71f6db-4dab-41ca-bd10-cd6204687b9d_snat","15"],["ct-zone-cfa46699-cc79-445e-a902-f1e37ff99806_dnat","5"],["ct-zone-cfa46699-cc
 
79-445e-a902-f1e37ff99806_snat","2"],["ct-zone-cr-lr_vcn0747157-ls_vcn0747157_external_ugw","9"],["ct-zone-cr-lr_vcn1645571_igw-ls_vcn1645571_external_igw","21"],["ct-zone-cr-lr_vcn7319607-ls_vcn7319607_external_ugw","14"],["ct-zone-cr-lr_vcn7319607_igw-ls_vcn7319607_external_igw","21"],["ct-zone-cr-lr_vcn7395327_igw-ls_vcn7395327_external_igw","21"],["ct-zone-cr-lr_vcn9567153-ls_vcn9567153_external_ugw","1"],["ct-zone-d0232f68-8d26-454c-87bf-e79066a1ed62_dnat","9"],["ct-zone-d0232f68-8d26-454c-87bf-e79066a1ed62_snat","8"],["ct-zone-d161aaef-e73e-452c-9d77-f465718f1f67_dnat","3"],["ct-zone-d161aaef-e73e-452c-9d77-f465718f1f67_snat","6"],["ct-zone-e2f0a229-15b0-4255-b52d-71b078239ed2_dnat","12"],["ct-zone-e2f0a229-15b0-4255-b52d-71b078239ed2_snat","13"],["ct-zone-e6986bf4-e813-4df0-9bfe-1de95ceb2e30_dnat","15"],["ct-zone-e6986bf4-e813-4df0-9bfe-1de95ceb2e30_snat","14"],["ct-zone-e93b7a93-8507-4036-8281-f2be764a44da_dnat","16"],["ct-zone-e93b7a93-8507-4036-8281-f2be764a44da_snat","17"
 
],["ct-zone-f3b9843a-d498-41dc-8244-0f87d9bc1384_dnat","6"],["ct-zone-f3b9843a-d498-41dc-8244-0f87d9bc1384_snat","7"],["ct-zone-f42fcb51-0af6-426f-974b-1478a169a70c_dnat","13"],["ct-zone-f42fcb51-0af6-426f-974b-1478a169a70c_snat","11"],["ct-zone-f708c12e-34b6-4657-b7d0-4b5ac5e0d6c7_dnat","20"],["ct-zone-f708c12e-34b6-4657-b7d0-4b5ac5e0d6c7_snat","19"],["ct-zone-ln-ls_vcn6603036_external_ugw","7"],["ct-zone-ln-ls_vcn7319607_external_igw","20"],["ct-zone-ln-ls_vcn7395327_external_ugw","7"],["ct-zone-ln-ls_vcn7836024_extern

Re: [ovs-discuss] [External] : Re: MAC_Binding\" table to have identical values

[Numan Siddique]

On Thu, Oct 21, 2021 at 6:43 AM Brendan Doyle  wrote:
>
>
>
> On 20/10/2021 21:29, Numan Siddique wrote:
> > On Mon, Oct 18, 2021 at 7:55 AM Daniel Alvarez Sanchez
> >  wrote:
> >>
> >>
> >> On Mon, Oct 18, 2021 at 1:12 PM Ammad Syed  wrote:
> >>> Hi Brendan,
> >>>
> >>> Not sure but this could be related to the patch below in neutron that was 
> >>> recently released.
> >>>
> >>> https://urldefense.com/v3/__https://opendev.org/openstack/neutron/commit/f6c35527698119ee6f73a6a3613c9beebb563840__;!!ACWV5N9M2RV99hQ!fKjD2ymIm0WKBrKvJ-6cjyKvYNJHCXYBXsL0nhWde_anAW_7exk9teq3h2_dRqFH1OI$
> >>
> >> Not really, as this commit that you refer to is to reduce the memory 
> >> footprint in the neutron-server process itself. Neutron never inserts 
> >> anything into the MAC_Binding table.
> >> However, we landed another patch [0] that will likely minimize this issue 
> >> as it will reduce the MAC_Binding insertions, limiting them only to MAC 
> >> addresses that need to be reached out by the overlay.
> >>
> >> Thanks!
> >> daniel
> >>
> >> [0] 
> >> https://urldefense.com/v3/__https://review.opendev.org/c/openstack/neutron/*/813610__;Kw!!ACWV5N9M2RV99hQ!fKjD2ymIm0WKBrKvJ-6cjyKvYNJHCXYBXsL0nhWde_anAW_7exk9teq3h2_dIMoCVyw$
> >>
> >>
> >>>
> >>> Ammad
> >>>
> >>> On Mon, Oct 18, 2021 at 3:40 PM Brendan Doyle  
> >>> wrote:
> >>>>
> >>>> I too am seeing many entries in the ovn-controller log like these:
> >>>>
> >>>> ovn/ovn-controller.log:2021-10-18T09:50:46.984Z|00164|ovsdb_idl|WARN|transaction
> >>>>  error: {"details":"Transaction causes multiple rows in \"MAC_Binding\" 
> >>>> table to have identical values (lr_vcn6727324-ls_vcn6727324_external_ugw 
> >>>> and \"253.255.80.18\") for index on columns \"logical_port\" and \"ip\". 
> >>>>  First row, with UUID 614509d1-5dfc-4268-94b7-6190c1bd8c58, was inserted 
> >>>> by this transaction.  Second row, with UUID 
> >>>> 5b56044f-7e62-4e6b-b559-2bca31ad5ab0, existed in the database before 
> >>>> this transaction and was not modified by the 
> >>>> transaction.","error":"constraint violation"}
> >>>>
> >>>>
> >>>> So with my limited understanding of the MAC_Binding table I'm wondering 
> >>>> are these benign?
> >>
> >> I think it's benign
> >>>>
> >>>> In that is it that we for what ever reason have decided that we need to 
> >>>> do an ARP to discover
> >>>> a MAC, then ovn-controller tries to add the discovered MAC to the 
> >>>> MAC_Binding only to find
> >>>> that it is already there. In which case the question is why was an ARP 
> >>>> request sent when
> >>>> we already had a MAC binding.
> > FYI,  ovn-controller also learns from the ARP requests received from
> > external which can be
> > turned off if desired with the option - always_learn_from_arp_request
> > set in the logical router's options
> > column.
> >
> > I don't think ovn-controller will generate an ARP request if its
> > already learnt.  Looks to me
> > multiple ovn-controller try to learn from an ARP request originated
> > from external and ofcourse
> > only one will be able to write to the mac_binding entry and others would 
> > fail.
>
> Yes that is possible, in which case the warnings are benign right?

Right.  I'd ignore these warnings.

Numan

>
> > Thanks
> > Numan
> >
> >
> >
> >>>> For me these are only ever seen on Distributed router Port Gateways.
> >>>>
> >>>>
> >>>> On 12/10/2021 13:06, Ammad Syed wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I am using openstack with ml2/ovn. I have two gateway chassis whenever I 
> >>>> shutdown one chassis and bring it back online, I see below error in 
> >>>> ovn-controller logs.
> >>>>
> >>>> Can you please advise the way to fix it ?
> >>>>
> >>>> 2021-10-12T11:49:22.124Z|00511|binding|INFO|cr-lrp-4c882760-15b1-4cf4-b680-53e0e928:
> >>>>  Claiming fa:16:3e:55:12:5a 101.53.244.97/24
> >>>> 2021-10-12T11:49:22.126Z|00512|b

Re: [ovs-discuss] MAC_Binding\" table to have identical values

[Numan Siddique]

On Mon, Oct 18, 2021 at 7:55 AM Daniel Alvarez Sanchez
 wrote:
>
>
>
> On Mon, Oct 18, 2021 at 1:12 PM Ammad Syed  wrote:
>>
>> Hi Brendan,
>>
>> Not sure but this could be related to the patch below in neutron that was 
>> recently released.
>>
>> https://opendev.org/openstack/neutron/commit/f6c35527698119ee6f73a6a3613c9beebb563840
>
>
> Not really, as this commit that you refer to is to reduce the memory 
> footprint in the neutron-server process itself. Neutron never inserts 
> anything into the MAC_Binding table.
> However, we landed another patch [0] that will likely minimize this issue as 
> it will reduce the MAC_Binding insertions, limiting them only to MAC 
> addresses that need to be reached out by the overlay.
>
> Thanks!
> daniel
>
> [0] https://review.opendev.org/c/openstack/neutron/+/813610
>
>
>>
>>
>> Ammad
>>
>> On Mon, Oct 18, 2021 at 3:40 PM Brendan Doyle  
>> wrote:
>>>
>>>
>>> I too am seeing many entries in the ovn-controller log like these:
>>>
>>> ovn/ovn-controller.log:2021-10-18T09:50:46.984Z|00164|ovsdb_idl|WARN|transaction
>>>  error: {"details":"Transaction causes multiple rows in \"MAC_Binding\" 
>>> table to have identical values (lr_vcn6727324-ls_vcn6727324_external_ugw 
>>> and \"253.255.80.18\") for index on columns \"logical_port\" and \"ip\".  
>>> First row, with UUID 614509d1-5dfc-4268-94b7-6190c1bd8c58, was inserted by 
>>> this transaction.  Second row, with UUID 
>>> 5b56044f-7e62-4e6b-b559-2bca31ad5ab0, existed in the database before this 
>>> transaction and was not modified by the transaction.","error":"constraint 
>>> violation"}
>>>
>>>
>>> So with my limited understanding of the MAC_Binding table I'm wondering are 
>>> these benign?
>
>
> I think it's benign
>>>
>>>
>>> In that is it that we for what ever reason have decided that we need to do 
>>> an ARP to discover
>>> a MAC, then ovn-controller tries to add the discovered MAC to the 
>>> MAC_Binding only to find
>>> that it is already there. In which case the question is why was an ARP 
>>> request sent when
>>> we already had a MAC binding.

FYI,  ovn-controller also learns from the ARP requests received from
external which can be
turned off if desired with the option - always_learn_from_arp_request
set in the logical router's options
column.

I don't think ovn-controller will generate an ARP request if its
already learnt.  Looks to me
multiple ovn-controller try to learn from an ARP request originated
from external and ofcourse
only one will be able to write to the mac_binding entry and others would fail.

Thanks
Numan



>>>
>>> For me these are only ever seen on Distributed router Port Gateways.
>>>
>>>
>>> On 12/10/2021 13:06, Ammad Syed wrote:
>>>
>>> Hi,
>>>
>>> I am using openstack with ml2/ovn. I have two gateway chassis whenever I 
>>> shutdown one chassis and bring it back online, I see below error in 
>>> ovn-controller logs.
>>>
>>> Can you please advise the way to fix it ?
>>>
>>> 2021-10-12T11:49:22.124Z|00511|binding|INFO|cr-lrp-4c882760-15b1-4cf4-b680-53e0e928:
>>>  Claiming fa:16:3e:55:12:5a 101.53.244.97/24
>>> 2021-10-12T11:49:22.126Z|00512|binding|INFO|Releasing lport 
>>> cr-lrp-4c882760-15b1-4cf4-b680-53e0e928 from this chassis.
>>> 2021-10-12T11:50:32.032Z|00513|ovsdb_idl|WARN|transaction error: 
>>> {"details":"Transaction causes multiple rows in \"MAC_Binding\" table to 
>>> have identical values (lrp-4c882760-15b1-4cf4-b680-53e0e928 and 
>>> \"fe80::6a4f:64ff:fef7:8c0\") for index on columns \"logical_port\" and 
>>> \"ip\".  First row, with UUID cbc847e6-75e4-4d73-9906-4fef221cad38, was 
>>> inserted by this transaction.  Second row, with UUID 
>>> bcac2e3e-5f32-411a-afcf-3249b85700f4, existed in the database before this 
>>> transaction and was not modified by the transaction.","error":"constraint 
>>> violation"}
>>>
>>> Ammad
>>>
>>> ___
>>> discuss mailing list
>>> disc...@openvswitch.org
>>> https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!eo4L8XZbywCy0zb_p7-7LEVv9xl6g9V8JEf6oZTAO21scCtNAudRSGcK9mYnI7H-cyA$
>>>
>>>
>>> ___
>>> discuss mailing list
>>> disc...@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
>>
>>
>> --
>> Regards,
>>
>>
>> Syed Ammad Ali
>> ___
>> discuss mailing list
>> disc...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [External] : Re: MAC_Binding\" table to have identical values

[Numan Siddique]

On Mon, Oct 18, 2021 at 9:01 AM Brendan Doyle  wrote:
>
>
> Actually looking at the comments in those patches I'm a little worried.
> The WARNs I see in the logs are for updates to the MAC for an underlay VIP.
> So if the VIP has moved and OVN tries to update the MAC_Binding  with the
> new MAC are these warnings suggesting that the update is ignored because we
> already have a binding entry for that logical port/IP? If so isn't that a bug?
> Or we we relying on that MAC being eventually aged out?
>

It's a good observation.   ovn-controller (pinctrl.c)  updates the MAC
if the entry for the VIP
already exists.

I'm not sure how realistic it would be for the below to happen
   (1)  ovn-controller on Chassis - C1 creates a mac binding entry for
- (VIP, MAC1, LP)
   (2) This VIP moves to another chassis - C2 with MAC2 and  suppose
ovn-controller on C2 has not yet
received the update of (1) from ovsdb-server yet
   (3) ovn-controller on C2 creates a new mac binding entry for -
(VIP, MAC2, LP).  But since the mac binding
entry for (VIP, LP) already exists, ovsdb-server would return
constraint violation error  and MAC2 is not
updated at all.

@Ammad Syed  Is it possible for you to verify if this is the case ?

Enable jsonrpc:dbg (ovn-appctl -t ovn-controller vlog/set jsonrpc:dbg)
and see if the MAC entry set in
the transaction is the same as the MAC stored in the SB DB ?
(ovn-sbctl find mac_binding ip=) ?


Otherwise the constraint violation warning can be ignored.


Thanks
Numan


>
> On 18/10/2021 12:54, Daniel Alvarez Sanchez wrote:
>
>
>
> On Mon, Oct 18, 2021 at 1:12 PM Ammad Syed  wrote:
>>
>> Hi Brendan,
>>
>> Not sure but this could be related to the patch below in neutron that was 
>> recently released.
>>
>> https://opendev.org/openstack/neutron/commit/f6c35527698119ee6f73a6a3613c9beebb563840
>
>
> Not really, as this commit that you refer to is to reduce the memory 
> footprint in the neutron-server process itself. Neutron never inserts 
> anything into the MAC_Binding table.
> However, we landed another patch [0] that will likely minimize this issue as 
> it will reduce the MAC_Binding insertions, limiting them only to MAC 
> addresses that need to be reached out by the overlay.
>
> Thanks!
> daniel
>
> [0] https://review.opendev.org/c/openstack/neutron/+/813610
>
>
>>
>>
>> Ammad
>>
>> On Mon, Oct 18, 2021 at 3:40 PM Brendan Doyle  
>> wrote:
>>>
>>>
>>> I too am seeing many entries in the ovn-controller log like these:
>>>
>>> ovn/ovn-controller.log:2021-10-18T09:50:46.984Z|00164|ovsdb_idl|WARN|transaction
>>>  error: {"details":"Transaction causes multiple rows in \"MAC_Binding\" 
>>> table to have identical values (lr_vcn6727324-ls_vcn6727324_external_ugw 
>>> and \"253.255.80.18\") for index on columns \"logical_port\" and \"ip\".  
>>> First row, with UUID 614509d1-5dfc-4268-94b7-6190c1bd8c58, was inserted by 
>>> this transaction.  Second row, with UUID 
>>> 5b56044f-7e62-4e6b-b559-2bca31ad5ab0, existed in the database before this 
>>> transaction and was not modified by the transaction.","error":"constraint 
>>> violation"}
>>>
>>>
>>> So with my limited understanding of the MAC_Binding table I'm wondering are 
>>> these benign?
>
>
> I think it's benign
>>>
>>>
>>> In that is it that we for what ever reason have decided that we need to do 
>>> an ARP to discover
>>> a MAC, then ovn-controller tries to add the discovered MAC to the 
>>> MAC_Binding only to find
>>> that it is already there. In which case the question is why was an ARP 
>>> request sent when
>>> we already had a MAC binding.
>>>
>>> For me these are only ever seen on Distributed router Port Gateways.
>>>
>>>
>>> On 12/10/2021 13:06, Ammad Syed wrote:
>>>
>>> Hi,
>>>
>>> I am using openstack with ml2/ovn. I have two gateway chassis whenever I 
>>> shutdown one chassis and bring it back online, I see below error in 
>>> ovn-controller logs.
>>>
>>> Can you please advise the way to fix it ?
>>>
>>> 2021-10-12T11:49:22.124Z|00511|binding|INFO|cr-lrp-4c882760-15b1-4cf4-b680-53e0e928:
>>>  Claiming fa:16:3e:55:12:5a 101.53.244.97/24
>>> 2021-10-12T11:49:22.126Z|00512|binding|INFO|Releasing lport 
>>> cr-lrp-4c882760-15b1-4cf4-b680-53e0e928 from this chassis.
>>> 2021-10-12T11:50:32.032Z|00513|ovsdb_idl|WARN|transaction error: 
>>> {"details":"Transaction causes multiple rows in \"MAC_Binding\" table to 
>>> have identical values (lrp-4c882760-15b1-4cf4-b680-53e0e928 and 
>>> \"fe80::6a4f:64ff:fef7:8c0\") for index on columns \"logical_port\" and 
>>> \"ip\".  First row, with UUID cbc847e6-75e4-4d73-9906-4fef221cad38, was 
>>> inserted by this transaction.  Second row, with UUID 
>>> bcac2e3e-5f32-411a-afcf-3249b85700f4, existed in the database before this 
>>> transaction and was not modified by the transaction.","error":"constraint 
>>> violation"}
>>>
>>> Ammad
>>>
>>> ___
>>> discuss mailing list
>>> disc...@openvswitch.org
>>> https://urldefense.com/

Re: [ovs-discuss] [OVN] branch name renamed from 'master' to 'main'

[Numan Siddique]

On Thu, Oct 7, 2021 at 9:36 AM Dumitru Ceara  wrote:
>
> On 10/7/21 2:26 PM, Aaron Conole wrote:
> > Aaron Conole  writes:
> >
> >> Dumitru Ceara  writes:
> >>
> >>> On 10/5/21 7:39 PM, Numan Siddique wrote:
> >>>> Hello everyone,
> >>>
> >>> Hi Numan,
> >>>
> >>> +Aaron
> >
> > I re-started those builds that would be associated with the series that
> > didn't get any tests.  I guess it should go through now.  Please let me
> > know if there is any further issue.
> >
>
> Looks good to me, thanks!

Thanks Aaron for fixing this quickly.

Numan

>
> >>>>
> >>>> The default branch of OVN has been renamed from 'master' to 'main'.  I
> >>>> had brought this up
> >>>>  for discussion in our weekly upstream OVN meeting a couple of weeks
> >>>> ago and the attendees were supportive of it.
> >>>>
> >>>> I followed the instructions from here -
> >>>> https://github.com/github/renaming  for the renaming.
> >>>>
> >>>> Request all the developers and users of OVN code base to update the
> >>>> default branch locally.
> >>>>
> >>>> Please let me know if this caused any issues so that this can be 
> >>>> resolved soon.
> >>>
> >>> I guess this change didn't make the ovsrobot too happy, I see there are
> >>> no test runs scheduled after the branch name change, even though OVN
> >>> patches were posted since then.
> >>
> >> Whoops - I didn't see this mentioned.  I'll fix it asap.
> >>
> >>>>
> >>>> Thanks
> >>>> Numan
> >>> Regards,
> >>> Dumitru
> >
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN at scale in production

[Numan Siddique]

On Wed, Oct 6, 2021 at 2:49 PM Seena Fallah  wrote:
>
> I'm using these versions on a centos container:
> ovsdb-server (Open vSwitch) 2.15.2
> ovn-nbctl 21.06.0
> Open vSwitch Library 2.15.90
> DB Schema 5.32.0
>
> Today I see the election timed out too and I should increase ovsdb election 
> timeout too. I saw the commits but I didn't find any related change to my 
> problem.
> If I use ovn 21.09 with ovsdb 2.16 Is there still any need to increase 
> election timeout and disable the inactivity probe?

Not sure on that.  It's worth a try if you have a test environment.

> Also is there any limitation on the number of ACLs that can OVN handle?

I don't think there is any limitation on the number of ACLs.  In
general as the size of the SB DB increases, we have seen issues.

Can you run the below command on each of your nodes where
ovn-controller runs and see if that helps ?

---
ovs-vsctl set open . external_ids:ovn-monitor-all=true
---

Thanks
Numan


>
> Thanks.
>
> On Wed, Oct 6, 2021 at 9:43 PM Numan Siddique  wrote:
>>
>> On Wed, Oct 6, 2021 at 12:15 PM Seena Fallah  wrote:
>> >
>> > Hi,
>> >
>> > I use ovn for OpenStack neutron plugin for my production. After days I see 
>> > issues about losing a leader in ovsdb. It seems it was because of the 
>> > failing inactivity probe and because I had 17k acls. After I disable the 
>> > inactivity probe it works fine but when I did a scale test on it (about 
>> > 40k ACLS) again it fails the leader.
>> > I saw many docs about ovn at scale issues that were raised by both RedHat 
>> > and eBay and seems the solution is to rewrite ovn with ddlog. I checked it 
>> > with northd-ddlog but nothing changes.
>> >
>> > My question is should I wait more for ovn to be stable for high scale or 
>> > is there any tuning I miss in my deployment?
>> > Also, will the ovn-nb/sb rewrite with ddlog and can help the issues at a 
>> > high scale? if yes is there any due time?
>>
>> What is the ovsdb-server version you're using ?  There are many
>> improvements in the ovsdb-server in 2.16.
>> Maybe that would help in your deployment.  And also there were many
>> improvements which went into OVN 21.09
>> if you want to test it out.
>>
>> Thanks
>> Numan
>>
>> >
>> > Thanks.
>> > ___
>> > discuss mailing list
>> > disc...@openvswitch.org
>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN at scale in production

[Numan Siddique]

On Wed, Oct 6, 2021 at 12:15 PM Seena Fallah  wrote:
>
> Hi,
>
> I use ovn for OpenStack neutron plugin for my production. After days I see 
> issues about losing a leader in ovsdb. It seems it was because of the failing 
> inactivity probe and because I had 17k acls. After I disable the inactivity 
> probe it works fine but when I did a scale test on it (about 40k ACLS) again 
> it fails the leader.
> I saw many docs about ovn at scale issues that were raised by both RedHat and 
> eBay and seems the solution is to rewrite ovn with ddlog. I checked it with 
> northd-ddlog but nothing changes.
>
> My question is should I wait more for ovn to be stable for high scale or is 
> there any tuning I miss in my deployment?
> Also, will the ovn-nb/sb rewrite with ddlog and can help the issues at a high 
> scale? if yes is there any due time?

What is the ovsdb-server version you're using ?  There are many
improvements in the ovsdb-server in 2.16.
Maybe that would help in your deployment.  And also there were many
improvements which went into OVN 21.09
if you want to test it out.

Thanks
Numan

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

[ovs-discuss] [OVN] branch name renamed from 'master' to 'main'

[Numan Siddique]

Hello everyone,

The default branch of OVN has been renamed from 'master' to 'main'.  I
had brought this up
 for discussion in our weekly upstream OVN meeting a couple of weeks
ago and the attendees were supportive of it.

I followed the instructions from here -
https://github.com/github/renaming  for the renaming.

Request all the developers and users of OVN code base to update the
default branch locally.

Please let me know if this caused any issues so that this can be resolved soon.

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

Re: [ovs-discuss] [External] : ACL logs severity seems to be ignored

[Numan Siddique]

On Tue, Sep 28, 2021 at 11:17 AM Brendan Doyle  wrote:
>
> Also the ovn-controller proc  is running with file log level info, which
> I would have taken that only
> ovn logs greater than info would have been logged:
>
> ovn-controller unix:/run/openvswitch/db.sock -vconsole:emer -vsyslog:err
> -vfile:info
>
> On 28/09/2021 15:04, Brendan Doyle wrote:
> > Folks,
> >
> >
> > I can't find anything in docs on how this is supposed to work, but I
> > would have assumed
> > that if I set the ACL severity to 'alert; then I would only get a log,
> > if a pkt were dropped.
> >
> > So for example i have an ACL rule:
> >
> >   to-lport 27000 (outport == @pg_vcn3_net1_sl3 && ip4.src ==
> > 192.16.1.0/24 && udp.dst == 111) allow-related
> > log(name=fss-14,severity=alert)
> >
> >
> > I don't want to see logs for pkts that match this, but I do:
> >
> >
> > ovn-controller.log:2021-09-28T13:32:25.759Z|00023|acl_log(ovn_pinctrl0)|INFO|name="fss-14",
> > verdict=allow, severity=alert:
> > udp,vlan_tci=0x,dl_src=40:44:00:00:00:a0,dl_dst=40:44:00:00:05:00,nw_src=192.16.1.6,nw_dst=192.16.1.106,nw_tos=0,nw_ecn=0,nw_ttl=63,tp_src=825,tp_dst=111
> >
> >
> > Is this the expected behavior?

Yes.  This is the expected behavior.  Basically if an ACL is matched,
then it is logged if 'log' flag is set.

https://github.com/ovn-org/ovn/blob/master/lib/acl-log.c#L79

Please see https://www.ovn.org/support/dist-docs/ovn-nb.5.html and
look for logging in ACL table section

-

Logging:

   These columns control whether and how OVN logs packets  that  match  an
   ACL.

   log: boolean
  If  set  to  true, packets that match the ACL will trigger a log
  message on the transport node or nodes that perform ACL process‐
  ing. Logging may be combined with any action.

  If  set  to  false,  the remaining columns in this group have no
  significance.

   name: optional string, at most 63 characters long
  This name, if it is provided, is included  in  log  records.  It
  provides the administrator and the cloud management system a way
  to associate a log record with a particular ACL.

   severity: optional string, one of alert, debug, info, notice, or  warn‐
   ing
  The severity of the ACL. The severity levels match those of sys‐
  log, in decreasing level of severity:  alert,  warning,  notice,
  info, or debug. When the column is empty, the default is info.

   meter: optional string
  The  name of a meter to rate-limit log messages for the ACL. The
  string must match the name column of a row in the  Meter  table.
  By  default,  log  messages  are  not  rate-limited. In order to
  ensure that the same Meter rate limits multiple ACL  logs  sepa‐
  rately, set the fair column.


And I don't think the log level of ACL is to match the log level set
on ovn-controller logging.

Thanks
Numan



> >
> > And if so is the option to avoid ovn-controller.log filling up to
> > either not log allowed matches or to rate limit them
> >
> > Thanks
> >
> >
> > Brendan
> >
> >
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!YD0EnKUmIwzV5ohd5PE93cJYjgF8LSeK8Qx5W4gG6mCbAsWsEKZQj3qx4XHPnd-OJZw$
>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovn] logical router port failover

[Numan Siddique]

On Sat, Sep 18, 2021 at 4:29 AM Ammad Syed  wrote:
>
> Hi,
>
> I am using openstack neutron and using distributed floating IP with ovn 
> backend. The VMs that have floating IP NATed have distributed traffic and its 
> traffic goes out directly from compute node uplink.
>
> While the traffic of SNAT goes from lrp that is scheduled on the gateway 
> chassis. Routers are scheduled on HA node.
>
> # ovn-nbctl list logical_router_port f3ab4336-559a-4081-b975-cf3c9a1dd6ad
> _uuid   : f3ab4336-559a-4081-b975-cf3c9a1dd6ad
> enabled : []
> external_ids: 
> {"neutron:network_name"=neutron-1ce2354f-7a83-45ab-80f5-1e9dc1c16be9, 
> "neutron:revision_number"="2341", 
> "neutron:router_name"="ed24659b-6345-4ea7-b651-b8a0af875b5e", 
> "neutron:subnet_ids"="d3c02380-17d3-4381-ac42-f1260e7f8b79"}
> gateway_chassis : [3bae14ea-6fe2-4c43-a8bb-1a99504662ef, 
> 42762997-1f91-404c-a170-3f6547b2e0a3, eb4f0959-d4b5-4129-8c02-6d48e15d3a68]
> ha_chassis_group: []
> ipv6_prefix : []
> ipv6_ra_configs : {}
> mac : "fa:16:3e:c5:c9:64"
> name: lrp-95b381bb-8dd7-47ba-a673-6724e8163c12
> networks: ["x.x.x.x/x"]
> options : {}
> peer: []
>
> How can I check that the router is currently scheduled on which chassis ? and 
> how to migrate manually gateway router (lrp) from one gateway chassis to 
> another gateway chassis ?

In your case you can either do

ovn-sbctl show and see which chassis has claimed the chassis redirect
port -  "cr-lrp-95b381bb-8dd7-47ba-a673-6724e8163c12"
or you can run

ovn-sbctl list port_binding cr-lrp-95b381bb-8dd7-47ba-a673-6724e8163c12

Normally the gateway chassis with the highest priority will claim the
cr-lrp-* port.
To move over to another gateway chassis you need to adjust the
priority accordingly.

I think the neutron ml2ovn driver manages the priority.  However you
can definitely override the priority  by running -
ovn-nbctl lrp-set-gateway-chassis
lrp-95b381bb-8dd7-47ba-a673-6724e8163c12

I'm not sure if the neutron ml2ovn driver would revert back your changes or not.

Thanks
Numan


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

Re: [ovs-discuss] [ovn] dnat_and_snat configuration question

[Numan Siddique]

On Thu, Sep 9, 2021 at 11:56 AM Odintsov Vladislav  wrote:
>
> Hi,
>
> There are some questions about NAT in OVN from me.
>
> 1. Is there any documentation about how GARP works in OVN with localnet ports?
> I see GARPs sending when new network is configured on the associated router 
> port (ovn-nbctl set logical-router-port  networks=" ")
>

Can you please see ovn-nb man page and grep for "nat-addresses" -
https://www.ovn.org/support/dist-docs/ovn-nb.5.html


> 2. I’m wonder if GARP should be sent when a new dnat_and_snat rule is added 
> to the edge LR.
> We’ve got cases, where in centralised topology administrator can reschedule 
> chassis for 1:1 outgoing traffic. In my understanding it’s just enough to set 
> new gateway chassis to wan logical router port and remove an old one. So, CR 
> lrp is moved to another chassis and should sent GARP to notify upstream 
> switches to update FDB. In my tests this is not executed, but may be I’m 
> configured something wrong.

If you configure nat-addresses=router for the logical switch port of
type router (connecting to the router port),  then ovn-controller will
send GARPs for NAT entries.

Obviously the logical switch would be also having a localnet port.
ovn-controller will generate GARPs and send them out
via the patch ports connecting the br-int to the provider bridge.


This is what the man page says


Options for router ports:

   These options apply when type is router.

   options : router-port: optional string
  Required. The name of the Logical_Router_Port to which this log‐
  ical switch port is connected.

   options : nat-addresses: optional string
  This is used to send  gratuitous  ARPs  for  SNAT  and  DNAT  IP
  addresses  via  the  localnet  port that is attached to the same
  logical switch as this type router port. This option  is  speci‐
  fied  on  a  logical  switch port that is connected to a gateway
  router, or a logical switch port that is connected to a distrib‐
  uted gateway port on a logical router.

  This must take one of the following forms:

  router Gratuitous ARPs will be sent for all SNAT and DNAT exter‐
 nal IP addresses and for all load balancer  IP  addresses
 defined  on  the  options:router-port’s  logical  router,
 using the options:router-port’s MAC address.

 This form of options:nat-addresses is valid  for  logical
 switch  ports  where options:router-port is the name of a
 port on a gateway router, or the name  of  a  distributed
 gateway port.

 Supported  only  in  OVN  2.8 and later. Earlier versions
 required NAT addresses to be manually synchronized.

  Ethernet address followed by one or more IPv4 addresses
 Example:  80:fa:5b:06:72:b7  158.36.44.22   158.36.44.24.
 This would result in generation of gratuitous ARPs for IP
 addresses  158.36.44.22  and  158.36.44.24  with  a   MAC
 address of 80:fa:5b:06:72:b7.

 This form of options:nat-addresses is only valid for log‐
 ical switch ports where options:router-port is  the  name
 of a port on a gateway router.
---


>
> 3. Do I need to configure an IP address to be an LRP network address for each 
> NAT 1:1 entry?

I didn't understand this question completely.   Which column of NAT
table are you referring to here ?
"logical_ip" column or "external_ip" column ?

Thanks
Numan

> Currently I have on wan port only one IP /32 and configured 0.0.0.0/0 route 
> via default GW with output_port set to LR’s wan port.
>
> Thanks.
>
> Regards,
> Vladislav Odintsov
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovn duplcate nat items cause DVR fip can not access

[Numan Siddique]

Hi,

OVN Northbound resources are created by neutron OVN mechanism driver.

Reporting this to the neutron mailing list would probably get you some reply.

Thanks
Numan


On Fri, Sep 10, 2021 at 12:26 PM 张兵兵  wrote:
>
> hi:
>
> i use openstack victoria ovn DVR to provide vpc network，and use octavia to 
> provide LB。
>
> At first(20210704),  my LB worked fine，and the nbctl show info is:
>
> (py3env) [root@control01 ~]# openstack port show 
> f53b6a55-6feb-4f98-bb28-875999cf577a
> +-+--+
> | Field   | Value 
>|
> +-+--+
> | admin_state_up  | UP
>|
> | allowed_address_pairs   |   
>|
> | binding_host_id | control03 
>|
> | binding_profile |   
>|
> | binding_vif_details | port_filter='True'
>|
> | binding_vif_type| ovs   
>|
> | binding_vnic_type   | normal
>|
> | created_at  | 2020-12-20T12:26:01Z  
>|
> | data_plane_status   | None  
>|
> | description |   
>|
> | device_id   | 18f83463-1f11-4905-ab44-92fd9364c8d4  
>|
> | device_owner| network:router_gateway
>|
> | dns_assignment  | None  
>|
> | dns_domain  | None  
>|
> | dns_name| None  
>|
> | extra_dhcp_opts |   
>|
> | fixed_ips   | ip_address='10.120.25.133', 
> subnet_id='e10a8459-5668-40f4-9ee7-8fb228201eb8' |
> | id  | f53b6a55-6feb-4f98-bb28-875999cf577a  
>|
> | ip_allocation   | None  
>|
> | mac_address | fa:16:3e:90:1f:56 
>|
> | name|   
>|
> | network_id  | 9989ffbf-6c71-47c9-b4bf-a747bc74f734  
>|
> | port_security_enabled   | False 
>|
> | project_id  |   
>|
> | propagate_uplink_status | None  
>|
> | qos_network_policy_id   | None  
>|
> | qos_policy_id   | None  
>|
> | resource_request| None  
>|
> | revision_number | 542   
>|
> | security_group_ids  |   
>|
> | status  | DOWN  
>|
> | tags|   
>|
> | trunk_details   | None  
>|
> | updated_at  | 2021-07-27T13:02:57Z  
>|
> +-+--+
>
>
> router 0a38aa37-6b88-4871-add0-dee277c0e54f 
> (neutron-18f83463-1f11-4905-ab44-92fd9364c8d4) (aka 
> cn-shanghai-on-prem-router)
> ...
> --
> nat 02d4cbf8-35e6-4842-8866-0331b025ca01
> external ip: "10.120.25.133"
> logical ip: "10.118.0.0/19"

Re: [ovs-discuss] WARN: execute ct(commit, zone=...) failed (Invalid argument)

[Numan Siddique]

On Fri, Sep 3, 2021 at 11:24 AM Odintsov Vladislav  wrote:
>
> Hi Ilya, Dumitru,
>
> for some reason I’ve found your answer only today.
>
> From the link you’ve sent I see there is a patch in kernel OVS code, but 
> current OVS master still has old version (if (err == NF_ACCEPT && ct->status 
> & IPS_SRC_NAT && ct->status & IPS_DST_NAT)).
>
> Shouldn’t this fix be backported to OVS tree as well?
> Can it solve my initial problem?
>
> Just in case, the error is next:
>
> 2021-09-03T14:41:42.960Z|6|dpif(handler3)|WARN|system@ovs-system: execute 
> ct(commit,zone=1,label=0/0x1),set(tunnel(tun_id=0x140016f4,dst=,ttl=64,tp_dst=7471,flags(df|csum|key))),1
>  failed (Invalid argument) on packet 
> tcp,vlan_tci=0x,dl_src=,dl_dst=,nw_src=,nw_dst=,nw_tos=0,nw_ecn=0,nw_ttl=63,tp_src=54136,tp_dst=5432,tcp_flags=psh|ack
>  tcp_csum:206a
>  with metadata 
> skb_priority(0),skb_mark(0),ct_state(0x21),ct_zone(0x1),ct_tuple4(src=,dst=,proto=6,tp_src=54136,tp_dst=5432),in_port(4)
>  mtu 0
>
> Thanks.


Do you use the OVS in-tree kernel module ?

Please check out https://github.com/openvswitch/ovs/blob/master/NEWS#L159

OVS in-tree kernel module is deprecated.

Thanks
Numan


>
> Regards,
> Vladislav Odintsov
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovn] OVN asymmetric routing with conntrack

[Numan Siddique]

On Mon, Aug 23, 2021 at 11:22 AM Vladislav Odintsov  wrote:
>
> Hi,
>
> we’ve faced an issue where asymmetric-routed traffic is used. Please help 
> understand what options do we have to allow such traffic.
>
> Topology is next:
>
>  client lsp (10.0.0.1/24)
>  |
> ls-external
> / \
> lsp router vm1 eth0: 10.0.0.2/24 lsp router vm2 eth0: 10.0.0.3/24
> lsp router vm1 eth1: 192.168.0.1/24  lsp router vm2 eth1: 192.168.0.2/24
> \ /
> ls-internal
>  |
> server lsp (192.168.0.10/24)
>
>
> All LSPs have port_security configured with " 0.0.0.0/0 ::/0" and belong 
> to port group pg1.
>
> There are two ACLs within this PG:
> from-lport 0.0.0.0/0 allow-related
> to-lport 0.0.0.0/0 allow-related
>
> The problem is when traffic from client to server goes through router vm1 and 
> returns through router vm2, there is no connectivity. I see reply traffic on 
> the server interface, which is going to router vm2 mac address, but I don't 
> see it on the router vm2 interface.
> I guess the reason for this is that conntrack first time sees packet for the 
> connection and ACK+SYN flags are set and treats this packet as invalid, right?

I think so.

>
> If yes, is there any option how to use asymmetric-routed topologies inside 
> OVN with stateful ACLs?
> I found there is an ability to replace ct.inv field check: 
> https://github.com/ovn-org/ovn/commit/3bb91366a6b0d60df5ce8f9c7f6427f7d37dfdd4
> Is it good idea to use this option to solve the issue or this is intended 
> specifically to use with smart NICs without invalid state support and can be 
> removed in future?
>

I do not understand your use case completely.  I'm not quite clear
from the diagram which all resources are external
and which all are part of OVN.  Have you tried using the ECMP routes feature ?

Regarding the ct.inv flag, does it work when you disable the usage of ct.inv ?

Thanks
Numan


If these routes are configured in the logical router, then
> Thanks.
>
> Regards,
> Vladislav Odintsov
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovn] recommended upgrade/restart procedure for ovn components

[Numan Siddique]

On Wed, Aug 18, 2021 at 1:47 PM Krzysztof Klimonda
 wrote:
>
> Hi Numan,
>
> On Wed, Aug 18, 2021, at 17:42, Numan Siddique wrote:
> > On Wed, Aug 18, 2021 at 3:55 AM Krzysztof Klimonda
> >  wrote:
> > >
> > > Hi,
> > >
> > > After reading OVN upgrade documentation[1], my understanding is that the 
> > > order of upgrading components is pretty important to ensure controlplane 
> > > & dataplane stability. As I understand those are the upgrade steps:
> >
> > >
> > > 1. upgrade and restart ovn-controller on every chassis
> > > 2. upgrade ovn-nb-db and ovn-sb-db and migrate database schema
> > > 3. upgrade ovn-northd as the last component
> >
> > Even though this is the recommended procedure,  I know that Openstack
> > tripleo deployments and Openshift upgrades the ovn-northd and
> > ovsdb-servers first
> >
> >
> > >
> > > First, is schema upgrade is done by ovn-ctl somehow? It didn't upgrade 
> > > schema for me and I had to run "ovsdb-client migrate" command on both 
> > > northbound and southbound databases.
> >
> > I think ovn-ctl should take care of upgrading the database to the
> > updated schema.  Before restarting the ovsdb-servers, the ovn packages
> > were upgraded to the desired schema files right ?
> > If so, I think ovn-ctl should upgrade the database.
>
> Yeah, those are kolla containers and after restart we use new image with new 
> ovn packages. This is how kolla starts northbound db: 
> "/usr/share/ovn/scripts/ovn-ctl run_nb_ovsdb --db-nb-addr=172.16.0.213 
> --db-nb-cluster-local-addr=172.16.0.213  --db-nb-sock=/run/ovn/ovnnb_db.sock 
> --db-nb-pid=/run/ovn/ovnnb_db.pid 
> --db-nb-file=/var/lib/openvswitch/ovn-nb/ovnnb.db 
> --ovn-nb-logfile=/var/log/kolla/openvswitch/ovn-nb-db.log" - I'll double 
> check if I can figure out why schema wasn't upgraded.


>
> >
> > >
> > > Second, in large deployments (250+ ovn-controllers) restarting ovn 
> > > southbound cluster nodes leads to complete failure of the southbound 
> > > database in my environment - once all ovn-controllers (and 
> > > neutron-ovn-metadata-agents) start reconnecting to the cluster, the load 
> > > generated by them makes cluster lose quorum, or even corrupt database on 
> > > some nodes.
> >
> > If there are a lot of connections to ovsdb-servers, it would
> > definitely slow down.   Maybe you can restart ovn-controllers in
> > phased manners ?  Or pause all ovn-controllers and then unpause them
> > in a few groups so that ovsdb-servers are not overloaded.
> > I think in one of our production scale deployments we did something similar.
>
> By pause do you mean "debug/pause"? Thanks, I'll check it out.

Yes.


>
> >
> >
> > > I'm running OVN 21.06 with ovsdb-server 2.14.0 - should I be upgrading to 
> > > 2.15.x? I've also seen the new relay-based architecture introduced in 
> > > 2.16.0 release but this seems be rather recent development and I'm 
> > > worried about stability (I've seen some report about crashes and high 
> > > memory usage).
> > >
> > > When running scale tests for ovn with kubernetes with hundreds of nodes, 
> > > how are cluster upgrades handled?
> >
> > As I mentioned above, I think in the case of openshift,  the master
> > nodes are upgraded first and then the worker nodes are upgraded.
> > I think during the master node upgrades, the worker nodes are paused.
> > My kubernetes/openshift knowledge is limited though.
>
> Thanks, any idea on upgrading ovsdb-server to 2.15.1 release? I see that 
> there is a new database format - would that give any performance boost to 
> northbound and southbound clusters? Or should I just start looking into 
> relay-based southbound deployment to scale my cluster to 200+ nodes?

If you want to try to relay deployment,  I'd suggest using 2.16.0.
I'm not really sure what improvements went in 2.15.1.  If you can, I'd
suggest moving to 2.16.0.

Thanks
Numan



>
> Thanks
> Krzysztof
>
> >
> > Thanks
> > Numan
> >
> > >
> > > Regards,
> > > Krzysztof
> > >
> > > [1] https://docs.ovn.org/en/latest/intro/install/ovn-upgrades.html
> > >
> > > --
> > >   Krzysztof Klimonda
> > >   kklimo...@syntaxhighlighted.com
> > > ___
> > > discuss mailing list
> > > disc...@openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> > >
> >
>
>
> --
>   Krzysztof Klimonda
>   kklimo...@syntaxhighlighted.com
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovn] recommended upgrade/restart procedure for ovn components

[Numan Siddique]

On Wed, Aug 18, 2021 at 3:55 AM Krzysztof Klimonda
 wrote:
>
> Hi,
>
> After reading OVN upgrade documentation[1], my understanding is that the 
> order of upgrading components is pretty important to ensure controlplane & 
> dataplane stability. As I understand those are the upgrade steps:

>
> 1. upgrade and restart ovn-controller on every chassis
> 2. upgrade ovn-nb-db and ovn-sb-db and migrate database schema
> 3. upgrade ovn-northd as the last component

Even though this is the recommended procedure,  I know that Openstack
tripleo deployments and Openshift upgrades the ovn-northd and
ovsdb-servers first


>
> First, is schema upgrade is done by ovn-ctl somehow? It didn't upgrade schema 
> for me and I had to run "ovsdb-client migrate" command on both northbound and 
> southbound databases.

I think ovn-ctl should take care of upgrading the database to the
updated schema.  Before restarting the ovsdb-servers, the ovn packages
were upgraded to the desired schema files right ?
If so, I think ovn-ctl should upgrade the database.


>
> Second, in large deployments (250+ ovn-controllers) restarting ovn southbound 
> cluster nodes leads to complete failure of the southbound database in my 
> environment - once all ovn-controllers (and neutron-ovn-metadata-agents) 
> start reconnecting to the cluster, the load generated by them makes cluster 
> lose quorum, or even corrupt database on some nodes.

If there are a lot of connections to ovsdb-servers, it would
definitely slow down.   Maybe you can restart ovn-controllers in
phased manners ?  Or pause all ovn-controllers and then unpause them
in a few groups so that ovsdb-servers are not overloaded.
I think in one of our production scale deployments we did something similar.


> I'm running OVN 21.06 with ovsdb-server 2.14.0 - should I be upgrading to 
> 2.15.x? I've also seen the new relay-based architecture introduced in 2.16.0 
> release but this seems be rather recent development and I'm worried about 
> stability (I've seen some report about crashes and high memory usage).
>
> When running scale tests for ovn with kubernetes with hundreds of nodes, how 
> are cluster upgrades handled?

As I mentioned above, I think in the case of openshift,  the master
nodes are upgraded first and then the worker nodes are upgraded.
I think during the master node upgrades, the worker nodes are paused.
My kubernetes/openshift knowledge is limited though.

Thanks
Numan

>
> Regards,
> Krzysztof
>
> [1] https://docs.ovn.org/en/latest/intro/install/ovn-upgrades.html
>
> --
>   Krzysztof Klimonda
>   kklimo...@syntaxhighlighted.com
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovn] Constant "Claiming virtual lport [uuid] for this chassis with the virtual parent [uuid]

[Numan Siddique]

On Tue, Aug 17, 2021 at 3:32 AM Krzysztof Klimonda
 wrote:
>
> Hi,
>
> In my deployment based on OVN 21.06, for virtual ports that are claimed on a 
> given chassis, the following log is appended ever 5 seconds to 
> ovn-controller.log:
>
> -
> 2021-08-17T07:27:34.214Z|05405|pinctrl|INFO|Claiming virtual lport 
> e11296f8-eb7f-4eef-8f2a-a40360ea061d for this chassis with the virtual parent 
> 96895f2e-c623-4928-83c1-a4aa128a874b
> 2021-08-17T07:27:39.214Z|05532|pinctrl|INFO|Claiming virtual lport 
> e11296f8-eb7f-4eef-8f2a-a40360ea061d for this chassis with the virtual parent 
> 96895f2e-c623-4928-83c1-a4aa128a874b
> -
>
> The time interval matches GARP packets sent from the amphora VM so my 
> understanding is that this message is logged for every GARP packet received 
> by local ovn-controller, but is there a need to append this log entry at INFO 
> level when the port is already claimed? Perhaps this should be only logged 
> when lport ownership changes for the first time (on vrrp failover for 
> example).

Yes.  That'd make sense.  Please feel free to propose a patch for it.

Thanks
Numan

>
> Regards,
> Krzysztof
>
> --
>   Krzysztof Klimonda
>   kklimo...@syntaxhighlighted.com
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss