Re: [ovs-discuss] Tunnel interface was deleted and recreated during ovs-vswitchd starts up

[张祖建 via discuss]

Tried on branch-3.1, branch-2.17, and branch-2.16, and all of them work
well.

Thanks very much!

Ilya Maximets  于2023年2月24日周五 00:41写道：

> On 2/22/23 02:31, 张祖建 wrote:
> > I'm using OVS v3.1 + OVN v22.12. Both Geneve and VXLAN have similar
> behavior.
>
> I think, I found the root cause of this behavior.
> Posted a patch to fix it here:
>
> https://patchwork.ozlabs.org/project/openvswitch/patch/20230223163927.915879-1-i.maxim...@ovn.org/
>
> Would be great if you can try it out.
>
> Best regards, Ilya Maximets.
>
> >
> > Ilya Maximets mailto:i.maxim...@ovn.org>>
> 于2023年2月22日周三 03:53写道：
> >
> > On 2/16/23 02:28, 张祖建 via discuss wrote:
> > > Hi all,
> > > I'm investigating packet drop during ovs restart/upgrade and found
> that the
> > > Gevene interface genev_sys_6082 was deleted and recreated during
> ovs-vswitchd
> > > starts up:
> > >
> > >
> > > root@node1:/root# ip -c a show genev_sys_6081
> > > 17: genev_sys_6081:  mtu 65000
> qdisc noqueue master ovs-system state UNKNOWN group default qlen 1000
> > > link/ether fa:1e:c7:a8:da:49 brd ff:ff:ff:ff:ff:ff
> > > root@node1:/root# ip monitor dev genev_sys_6081
> > > 17: genev_sys_6081:  mtu 65000
> qdisc noqueue state UNKNOWN group default
> > > link/ether fa:1e:c7:a8:da:49 brd ff:ff:ff:ff:ff:ff
> > > 17: genev_sys_6081:  mtu 65000
> qdisc noqueue state UNKNOWN group default
> > > link/ether fa:1e:c7:a8:da:49 brd ff:ff:ff:ff:ff:ff
> > > 17: genev_sys_6081:  mtu 65000 qdisc noqueue
> state DOWN group default
> > > link/ether fa:1e:c7:a8:da:49 brd ff:ff:ff:ff:ff:ff
> > > Deleted 17: genev_sys_6081:  mtu 65000 qdisc
> noop state DOWN group default
> > > link/ether fa:1e:c7:a8:da:49 brd ff:ff:ff:ff:ff:ff
> > > ^C
> > > root@node1:/root# ip -c a show genev_sys_6081
> > > 18: genev_sys_6081:  mtu 65000
> qdisc noqueue master ovs-system state UNKNOWN group default qlen 1000
> > > link/ether 7a:b4:13:b8:c0:4f brd ff:ff:ff:ff:ff:ff
> > >
> > >
> > > Is this behavior by design? How can I avoid tunnel interface
> recreation?
> >
> > Hi.
> >
> > No, that should not happen in general.  Ports should not be deleted
> > and re-created on restart.
> >
> > What version of OVS you have?  There was a bug in v2.15.0 that could
> > cause this kind of behavior.
> >
> > Best regards, Ilya Maximets.
> >
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] how to set a rule that destination not equal

[Ilya Maximets via discuss]

On 2/24/23 01:21, Ilya Maximets wrote:
> On 2/24/23 00:36, Dr. Omran via discuss wrote:
>> is it programmble? i mean: ex.  nw_dst!=10.147.20.0/24 ?
> 
> No, inequality check is not supported in OpenFlow.
> 
>>
>> i misunderstand your example, i think you mean the enable the allowed 
>> network, which is the other ip.
>> I want to clarify.
>> Here in this bridge, I have two traffic only
>> 1- from 10.147.20.0/24 other ports on the bridge.
>> 2- outside the bridge to the local ethernet port 192.168.188.0/24
>>
>> I want to disable traffic outside the bridge from interface enp1s0f0, which 
>> is connected to the NAS driver, so that it is not open to the internet.
>>
>> i think the rule should be as follows, to accept traffic to 10.147.20.0/24 
>> and other than that reject?
>>
>> priority=200,in_port=enp1s0f0,ip,nw_dst=10.147.20.0/24,actions=accept
>> priority=199,in_port=enp1s0f0,ip,actions=drop
> 
> Sorry, I messed up IPs in my example.  Your version is what I wanted to say.
> 
> 
> Alternative is to do this (you probably shouldn't use that):
> 
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.1.0/0.0.1.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.2.0/0.0.2.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.0.4.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.8.0/0.0.8.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.0.16.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.32.0/0.0.32.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.64.0/0.0.64.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.128.0/0.0.128.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.1.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.2.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.4.0.0/0.4.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.8.0.0/0.8.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.16.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.32.0.0/0.32.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.64.0.0/0.64.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.128.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=1.0.0.0/1.0.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/2.0.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=4.0.0.0/4.0.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/8.0.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=16.0.0.0/16.0.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=32.0.0.0/32.0.0.0,actions=drop
> priority=200,in_port=enp1s0f0,ip,nw_dst=64.0.0.0/64.0.0.0,actions=drop

One more:
priority=200,in_port=enp1s0f0,ip,nw_dst=128.0.0.0/128.0.0.0,actions=drop

> 
> It's very non-intuitive way of doing things, but it should work.
> What we do is matching on opposite of every bit in 10.147.20.0/24.
> 24 bits total - 24 rules.  Can potentially be optimized.
> 
> I generated above rules with the following python script:
> 
> import ipaddress
> addr = int(ipaddress.ip_address('10.147.20.0'))
> for i in range(8, 31):

Should be range(8, 32), of course.

> print('priority=200,in_port=enp1s0f0,ip,nw_dst=%s/%s,actions=drop' % (
> ipaddress.ip_address((addr & (1 << i)) ^ (1 << i)),
> ipaddress.ip_address(1 << i)))
> 
>>
>>
>>
>> thank you
>>
>> kind regards
>> Sherif Omran
>>
>>
>>
>> On Thu, Feb 23, 2023 at 3:25 PM Ilya Maximets > > wrote:
>>
>> On 2/23/23 14:26, Dr. Omran via discuss wrote:
>> > Hello guys,
>> >
>> > i want to do this rule but instead of giving the destination as ip, i 
>> want to say a destination that is not equal to 10.147.20.0/24
>> >
>> > ovs-ofctl add-flow br0 
>> "priority=200,ip,nw_dst=192.168.188.0/24,in_port=enp1s0f0,actions=drop"
>> >
>> > how do you do it?
>>
>> You either carefully craft multiple rules that cover all the subnets
>> outside of 192.168.188.0/24 , or you create a high priority rule that
>> matches on 192.168.188.0/24 and does something else (jumps to another
>> tbale, for example) and have a lower priority rule that doesn't have
>> a match on nw_dst and drops all the traffic, e.g.:
>>
>>   
>> priority=200,in_port=enp1s0f0,ip,nw_dst=192.168.188.0/24,actions=do_something_else
>>   priority=199,in_port=enp1s0f0,ip,actions=drop
>>
>> Best regards, Ilya Maximets.
>>
>>
>> ___
>> 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 set a rule that destination not equal

[Ilya Maximets via discuss]

On 2/24/23 00:36, Dr. Omran via discuss wrote:
> is it programmble? i mean: ex.  nw_dst!=10.147.20.0/24 ?

No, inequality check is not supported in OpenFlow.

> 
> i misunderstand your example, i think you mean the enable the allowed 
> network, which is the other ip.
> I want to clarify.
> Here in this bridge, I have two traffic only
> 1- from 10.147.20.0/24 other ports on the bridge.
> 2- outside the bridge to the local ethernet port 192.168.188.0/24
> 
> I want to disable traffic outside the bridge from interface enp1s0f0, which 
> is connected to the NAS driver, so that it is not open to the internet.
> 
> i think the rule should be as follows, to accept traffic to 10.147.20.0/24 
> and other than that reject?
> 
> priority=200,in_port=enp1s0f0,ip,nw_dst=10.147.20.0/24,actions=accept
> priority=199,in_port=enp1s0f0,ip,actions=drop

Sorry, I messed up IPs in my example.  Your version is what I wanted to say.


Alternative is to do this (you probably shouldn't use that):

priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.1.0/0.0.1.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.2.0/0.0.2.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.0.4.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.8.0/0.0.8.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.0.16.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.32.0/0.0.32.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.64.0/0.0.64.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.128.0/0.0.128.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.1.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.2.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.4.0.0/0.4.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.8.0.0/0.8.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.16.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.32.0.0/0.32.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.64.0.0/0.64.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/0.128.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=1.0.0.0/1.0.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/2.0.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=4.0.0.0/4.0.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=0.0.0.0/8.0.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=16.0.0.0/16.0.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=32.0.0.0/32.0.0.0,actions=drop
priority=200,in_port=enp1s0f0,ip,nw_dst=64.0.0.0/64.0.0.0,actions=drop

It's very non-intuitive way of doing things, but it should work.
What we do is matching on opposite of every bit in 10.147.20.0/24.
24 bits total - 24 rules.  Can potentially be optimized.

I generated above rules with the following python script:

import ipaddress
addr = int(ipaddress.ip_address('10.147.20.0'))
for i in range(8, 31):
print('priority=200,in_port=enp1s0f0,ip,nw_dst=%s/%s,actions=drop' % (
ipaddress.ip_address((addr & (1 << i)) ^ (1 << i)),
ipaddress.ip_address(1 << i)))

> 
> 
> 
> thank you
> 
> kind regards
> Sherif Omran
> 
> 
> 
> On Thu, Feb 23, 2023 at 3:25 PM Ilya Maximets  > wrote:
> 
> On 2/23/23 14:26, Dr. Omran via discuss wrote:
> > Hello guys,
> >
> > i want to do this rule but instead of giving the destination as ip, i 
> want to say a destination that is not equal to 10.147.20.0/24
> >
> > ovs-ofctl add-flow br0 
> "priority=200,ip,nw_dst=192.168.188.0/24,in_port=enp1s0f0,actions=drop"
> >
> > how do you do it?
> 
> You either carefully craft multiple rules that cover all the subnets
> outside of 192.168.188.0/24 , or you create a high priority rule that
> matches on 192.168.188.0/24 and does something else (jumps to another
> tbale, for example) and have a lower priority rule that doesn't have
> a match on nw_dst and drops all the traffic, e.g.:
> 
>   
> priority=200,in_port=enp1s0f0,ip,nw_dst=192.168.188.0/24,actions=do_something_else
>   priority=199,in_port=enp1s0f0,ip,actions=drop
> 
> Best regards, Ilya Maximets.
> 
> 
> ___
> 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] Bond interface through bridge?

[Alex Zetaeffesse via discuss]

Well, I think my confusion comes from the fact that with Linux you can have
a bond interface, whereas in OVS it always just a port.

Alex

On Thu, Feb 23, 2023 at 12:01 AM Alex Zetaeffesse  wrote:

> Hi,
>
> I searched the Internet for the answer, but so far I haven't found it.
>
> Can anybody tell me why when creating an OVS bond interface I have to link
> it to a bridge, that must of course exist?
> This is not required through the Linux way where a bond is created
> straight-away as a port.
> Even more weird, in the help of ovs-vsctl I read
>
> *Port commands (a bond is considered to be a single port):*
>
> So for OVS a bond is a port. For me that's the difficult part to
> understand.
> Since I'm thinking of moving from Linux to OVS due to the SDN management
> in
> ProxMox, I would like to get it right.
>
> TIA,
> Alex
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] how to set a rule that destination not equal

[Dr. Omran via discuss]

is it programmble? i mean: ex.  nw_dst!=10.147.20.0/24 ?

i misunderstand your example, i think you mean the enable the allowed
network, which is the other ip.
I want to clarify.
Here in this bridge, I have two traffic only
1- from 10.147.20.0/24 other ports on the bridge.
2- outside the bridge to the local ethernet port 192.168.188.0/24

I want to disable traffic outside the bridge from interface enp1s0f0, which
is connected to the NAS driver, so that it is not open to the internet.

i think the rule should be as follows, to accept traffic to 10.147.20.0/24
and other than that reject?

priority=200,in_port=enp1s0f0,ip,nw_dst=10.147.20.0/24,actions=
accept
priority=199,in_port=enp1s0f0,ip,actions=drop



thank you

kind regards
Sherif Omran



On Thu, Feb 23, 2023 at 3:25 PM Ilya Maximets  wrote:

> On 2/23/23 14:26, Dr. Omran via discuss wrote:
> > Hello guys,
> >
> > i want to do this rule but instead of giving the destination as ip, i
> want to say a destination that is not equal to 10.147.20.0/24 <
> http://10.147.20.0/24>
> >
> > ovs-ofctl add-flow br0 "priority=200,ip,nw_dst=
> 192.168.188.0/24,in_port=enp1s0f0,actions=drop"
> >
> > how do you do it?
>
> You either carefully craft multiple rules that cover all the subnets
> outside of 192.168.188.0/24, or you create a high priority rule that
> matches on 192.168.188.0/24 and does something else (jumps to another
> tbale, for example) and have a lower priority rule that doesn't have
> a match on nw_dst and drops all the traffic, e.g.:
>
>   priority=200,in_port=enp1s0f0,ip,nw_dst=
> 192.168.188.0/24,actions=do_something_else
>   priority=199,in_port=enp1s0f0,ip,actions=drop
>
> Best regards, Ilya Maximets.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] how to set a rule that destination not equal

[Dr. Omran via discuss]

Hello guys,

i want to do this rule but instead of giving the destination as ip, i want
to say a destination that is not equal to 10.147.20.0/24

ovs-ofctl add-flow br0 "priority=200,ip,nw_dst=
192.168.188.0/24,in_port=enp1s0f0,actions=drop"

how do you do it?

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

Re: [ovs-discuss] Tunnel interface was deleted and recreated during ovs-vswitchd starts up

[Ilya Maximets via discuss]

On 2/22/23 02:31, 张祖建 wrote:
> I'm using OVS v3.1 + OVN v22.12. Both Geneve and VXLAN have similar behavior.

I think, I found the root cause of this behavior.
Posted a patch to fix it here:
  
https://patchwork.ozlabs.org/project/openvswitch/patch/20230223163927.915879-1-i.maxim...@ovn.org/

Would be great if you can try it out.

Best regards, Ilya Maximets.

> 
> Ilya Maximets mailto:i.maxim...@ovn.org>> 于2023年2月22日周三 
> 03:53写道：
> 
> On 2/16/23 02:28, 张祖建 via discuss wrote:
> > Hi all,
> > I'm investigating packet drop during ovs restart/upgrade and found that 
> the
> > Gevene interface genev_sys_6082 was deleted and recreated during 
> ovs-vswitchd
> > starts up:
> >
> >
> > root@node1:/root# ip -c a show genev_sys_6081
> > 17: genev_sys_6081:  mtu 65000 qdisc 
> noqueue master ovs-system state UNKNOWN group default qlen 1000
> >     link/ether fa:1e:c7:a8:da:49 brd ff:ff:ff:ff:ff:ff
> > root@node1:/root# ip monitor dev genev_sys_6081
> > 17: genev_sys_6081:  mtu 65000 qdisc 
> noqueue state UNKNOWN group default
> >     link/ether fa:1e:c7:a8:da:49 brd ff:ff:ff:ff:ff:ff
> > 17: genev_sys_6081:  mtu 65000 qdisc 
> noqueue state UNKNOWN group default
> >     link/ether fa:1e:c7:a8:da:49 brd ff:ff:ff:ff:ff:ff
> > 17: genev_sys_6081:  mtu 65000 qdisc noqueue state 
> DOWN group default
> >     link/ether fa:1e:c7:a8:da:49 brd ff:ff:ff:ff:ff:ff
> > Deleted 17: genev_sys_6081:  mtu 65000 qdisc noop 
> state DOWN group default
> >     link/ether fa:1e:c7:a8:da:49 brd ff:ff:ff:ff:ff:ff
> > ^C
> > root@node1:/root# ip -c a show genev_sys_6081
> > 18: genev_sys_6081:  mtu 65000 qdisc 
> noqueue master ovs-system state UNKNOWN group default qlen 1000
> >     link/ether 7a:b4:13:b8:c0:4f brd ff:ff:ff:ff:ff:ff
> >
> >
> > Is this behavior by design? How can I avoid tunnel interface recreation?
> 
> Hi.
> 
> No, that should not happen in general.  Ports should not be deleted
> and re-created on restart.
> 
> What version of OVS you have?  There was a bug in v2.15.0 that could
> cause this kind of behavior.
> 
> Best regards, Ilya Maximets.
> 

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

Re: [ovs-discuss] how to set a rule that destination not equal

[Ilya Maximets via discuss]

On 2/23/23 14:26, Dr. Omran via discuss wrote:
> Hello guys,
> 
> i want to do this rule but instead of giving the destination as ip, i want to 
> say a destination that is not equal to 10.147.20.0/24 
> 
> ovs-ofctl add-flow br0 
> "priority=200,ip,nw_dst=192.168.188.0/24,in_port=enp1s0f0,actions=drop"
> 
> how do you do it?

You either carefully craft multiple rules that cover all the subnets
outside of 192.168.188.0/24, or you create a high priority rule that
matches on 192.168.188.0/24 and does something else (jumps to another
tbale, for example) and have a lower priority rule that doesn't have
a match on nw_dst and drops all the traffic, e.g.:

  
priority=200,in_port=enp1s0f0,ip,nw_dst=192.168.188.0/24,actions=do_something_else
  priority=199,in_port=enp1s0f0,ip,actions=drop

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

[ovs-discuss] how to set a rule that destination not equal

[Dr. Omran via discuss]

 Hello guys,

i want to do this rule but instead of giving the destination as ip, i want
to say a destination that is not equal to 10.147.20.0/24

ovs-ofctl add-flow br0 "priority=200,ip,nw_dst=
192.168.188.0/24,in_port=enp1s0f0,actions=drop"

how do you do it?

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

Re: [ovs-discuss] Problem with ovn and neutron dynamic routing

[Plato, Michael via discuss]

Hello,

many thanks for the quick response. As I can see, the ticket is a bit older. 
Are there any ideas for a solution so far or first patches that could be tested?

Best regards

Michael

Von: Luis Tomas Bolivar 
Gesendet: Montag, 20. Februar 2023 10:03
An: Plato, Michael 
Cc: ovs-discuss@openvswitch.org
Betreff: Re: [ovs-discuss] Problem with ovn and neutron dynamic routing

We hit this problem a while ago and reported it here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1906455

On Mon, Feb 20, 2023 at 9:56 AM Plato, Michael via discuss 
mailto:ovs-discuss@openvswitch.org>> wrote:
Hello,

we have a problem with ovn in connection with neutron dynamic routing (which is 
now supported with ovn). We can announce our internal networks via BGP and the 
VMs in this network can also be reached directly without nat.
But if we attach a public floating ip to the internal self service network ip, 
we have some strange effects. The VM can still be reached via ping with both 
ips. But SSH for example only works via floating ip. I did some network traces 
and found that the return traffic is being natted even though no nat was 
applied on incoming way. From my point of view we need a conntrack marker which 
identifies traffic which was d-natted on incoming way and s-nat only those 
traffic on return way. Is it possible to implement something like this to fully 
support ovn with BGP announced networks which are directly reachable via 
routing?

Thanks for reply and best regards!

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


--
LUIS TOMÁS BOLÍVAR
Principal Software Engineer
Red Hat
Madrid, Spain
ltoma...@redhat.com

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