user]# ovn-controller --version
> ovn-controller *23.09.1*
Are you building this package yourself? If so, on which exact commit it is
based?
If not, what distribution are you using and what is the exact rpm/deb package
version?
My suspicion is that it is not exactly v23.09.1, but a code a few comm
On 5/27/24 20:31, Roberto Bartzen Acosta wrote:
> Thanks Ilya!
>
> Em seg., 27 de mai. de 2024 às 10:28, Ilya Maximets <mailto:i.maxim...@ovn.org>> escreveu:
>
> On 5/27/24 18:22, Roberto Bartzen Acosta via discuss wrote:
> > Hello everyone!
>
te when we create
> a transit-switch. If the table did not have this index the problem would not
> be observed.
>
> This issue affects applications such as: neutron-server,
> neutron-ovn-metadata-agent, and everyone that monitors the Datapath_Binding
> table via python-idl.
>
kev2=insist
Changing these options will require changing the code of the
ovs-monitor-ipsec daemon. Which is a python script, so should
not be difficult if necessary.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.op
command
line argument or equivalent database configuration. But I would
expect that compliant OpenSSL build will not contain non-compliant
algorithms.
Best regards, Ilya Maximets.
>
> On Mon, May 13, 2024 at 2:39 AM Ilya Maximets <mailto:i.maxim...@ovn.org>> wrote:
>
>
But again, you need to ask your distribution.
Best regards, Ilya Maximets.
>
> Maybe my question is not described accurately. Please let me know
> what more information is needed.
>
> Thanks.
___
discuss mailing list
disc.
userspace datapath.
>
> Gav
>
> On Fri, 26 Apr 2024 at 12:42, Ilya Maximets wrote:
>>
>> On 4/26/24 20:12, Gavin McKee wrote:
>>> Thanks for coming back to me on this.
>>>
>>> Moving kernal versions around is not a straightforward option here -
&
t know if it is causing your issue, but it is
a severe bug that can potentially be a cause):
1. Re-build the kernel to include the fix.
2. Downgrade from 9.3 to an earlier release.
3. Wait for 9.4.
Best regards, Ilya Maximets.
>
> Gav
>
> On Wed, 24 Apr 2024 at 04:44, Ilya Maximets wro
On 4/25/24 11:51, Vladislav Odintsov wrote:
>
>
>> On 25 Apr 2024, at 12:20, Ilya Maximets wrote:
>>
>> On 4/25/24 10:53, Vladislav Odintsov wrote:
>>> Hi Ilya,
>>>
>>> I’ve got question regarding upgrade of clustered ovsdb-servers
or versions,
so it's not an officially supported upgrade path, but it is there if
you know what are you doing.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
y also indicate a
problem with incremental processing in ovn-controller.
Next time the issue happens try to force flow recompute with
ovn-appctl -t ovn-controller recompute
And see if that fixes the issue. If it does, it would be great
to have OpenFlow dumps before and after the recompute for
comparison.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 4/24/24 12:12, Ilya Maximets wrote:
> On 4/24/24 05:32, Wang, Fei2 via discuss wrote:
>> Hi all,
>>
>>
>>
>> We are hitting below error when trying to start ovsdb-server 3.3.0 on SLES15
>> SP5, I don’t tend to believe this issue is related to OS but
figuration to set up the prefixes:
./configure --prefix=/usr/local \
--localstatedir=/usr/local/var \
--sysconfdir=/usr/local/etc
Another option is to provide --pidfile option to ovsdb-server
specifying the desired location.
Best regards, Ilya Maximets.
On 4/4/24 18:07, Brian Haley wrote:
> Hi,
>
> On 4/4/24 6:12 AM, Ilya Maximets wrote:
>> On 4/3/24 22:15, Brian Haley via discuss wrote:
>>> Hi,
>>>
>>> I recently have been seeing issues in a large environment where the
>>> listen backlog of o
t loop iteration. But we
need to be careful here as handling multiple initial monitor requests
for the database within a single iteration may be costly and may reduce
overall responsiveness of the server. Needs some research.
Having hundreds leader-only clients for Nb still sounds a little strang
l be:
# ovs-vsctl clear bridge ovs-default mirrors
If you only want to remove this particular mirror:
# ovs-vsctl remove bridge ovs-default mirrors
b20f3ce4-c5c2-453a-9fa4-99175be0a02a
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@open
ld expect
at least 10x performance improvement from it, maybe even more.
Best regards, Ilya Maximets.
> - Routers – approx. 5K
>
> (link1):
> https://github.com/ovn-org/ovn/commit/db4cb7098c890e974175d4d05dd70dc409fad91e
>
> Yours truly, George
_
dropping tunneled
>> traffic when userspace-tso is enabled.
>>
>> Would be great if you can test it out.
>
> Hi Ilya,
>
> thanks for the fix.
> It works great for me.
Thanks for testing!
Best regards, Ilya Maximets.
>
>
On 11/1/22 13:30, Donald Sharp wrote:
>
>
> On Mon, Oct 31, 2022 at 5:54 PM Ilya Maximets <mailto:i.maxim...@ovn.org>> wrote:
>
> On 10/31/22 17:25, Donald Sharp via discuss wrote:
> > Hi!
> >
> > I work on the FRRouting project (https
to take, however, there is
still an issue with miniflow_extract() requesting UDP checksum offload
not realizing that it requests it for an inner header.
IMHO, the fact that flag can mean different things at different times
is the root of many of the problems with offloading and we'll keep
get
generic build, then you'll need to get source rpm, make
changes in it and re-build the RPM.
An easier way might be to just build and install a new kernel altogether
from an upstream repo.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
is particular situation hwoever would be enabling support
for lb-output action on the bond:
ovs-vsctl set Port bond0 other_config:lb-output-action=true
This should avoid the recirculation in this particular scenario.
But we still need to find a solution for the recirculation issue.
Best regards, Il
t; :target: https://ci.appveyor.com/project/blp/ovs/history
> .. image:: https://api.cirrus-ci.com/github/openvswitch/ovs.svg
> :target: https://cirrus-ci.com/github/openvswitch/ovs
> diff --git a/appveyor.yml b/appveyor.yml
> index 29cc44d6c6f6..65e29eb4e3be 100644
> --- a/appveyor.yml
> +++ b/appveyor.yml
> @@ -2,7 +2,7 @@ version: 1.0.{build}
> image: Visual Studio 2019
> branches:
>only:
> - - master
> + - main
Should be done in two stages as described above.
> configuration:
>- Debug
>- Release
> @@ -23,7 +23,7 @@ install:
> New-Item -ItemType Directory -Force -Path C:\ovs-build-downloads
>
> # Find and download the latest stable OpenSSl 3.0.
> -$URL =
> "https://raw.githubusercontent.com/slproweb/opensslhashes/master/win32_openssl_hashes.json;
> +$URL =
> "https://raw.githubusercontent.com/slproweb/opensslhashes/main/win32_openssl_hashes.json;
As mentioned in the other email, this is not a correct change
as it is not our repo.
> $webData = (Invoke-WebRequest -Uri $URL).content | ConvertFrom-Json
> $source = ($webData.files.PSObject.Properties | Where-Object {
> $_.Value.basever -match "3.0.*" -and
> @@ -74,6 +74,6 @@ build_script:
> c:\OpenvSwitch-$env:CONFIGURATION.msi
>
> after_build:
> -- ps: 7z a C:\ovs-master-$env:CONFIGURATION.zip C:\openvswitch
> -- ps: Push-AppveyorArtifact C:\ovs-master-$env:CONFIGURATION.zip
> +- ps: 7z a C:\ovs-main-$env:CONFIGURATION.zip C:\openvswitch
> +- ps: Push-AppveyorArtifact C:\ovs-main-$env:CONFIGURATION.zip
> - ps: Push-AppveyorArtifact C:\OpenvSwitch-$env:CONFIGURATION.msi
>
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
hema knowledge, but it tries to
be compatible with different versions as well, IIRC.
CC: Terry, he may have some more details on this.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
hey'll all be
re-tried,
but it's better to connect to the leader instead for write-heavy operations.
In the past ovn-kubernetes used a version of libovsdb that wouldn't re-connect
to a new leader and would keep sending transactions through the follower causing
a lot of such logs. But it was Northboun
ecurity issue, because the code in question is not
reachable, however, for the future, please report security issues
to ovs-secur...@openvswitch.org instead of public forums. Thanks!
If you want to make a cosmetic change removing the incorrect
ovsdb_transaction_abort() call, feel free to
tion? Also, the tag 0 is a special value that can be ignored,
so I'd advise to not use it.
2. Change the type from access to dot1q-tunnel. This way double tagging
will be allowed and the packets should not be dropped anymore.
I don't think the vlan check can be easily removed from th
lt
value is 1 and that may be one reason why packets are not delivered
to mitapVm72. ofproto/trace should be able to confirm if that is
the case.
Best regards, Ilya Maximets.
>
> 1、ovs version: 3.2.1
> 2、Bridge
> [root@localhost openvswitch-3.2.1]# ovs-vsctl show
> Bridge vds1
veth interfaces the same way it removes them
from internal ports. There is no special treatment, AFAIK. That was
the point of my reply.
Ingress qdiscs will be removed from any port attached to OVS. Egress
qdiscs will also be removed, unless linux-noop QoS type is configured.
Best regards, Ilya M
ry it?
The change will log an error message and abort the process if we happen
to enter quiescent state while iterating over the hash map. Core dump
will point to a problematic call.
Best regards, Ilya Maximets.
>
>> LIU Yulong
>>
>>
>> On Mon, Feb 26, 2024 at 5:41 PM
show',
OVS will manage qdiscs on that interface.
Bets regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 2/19/24 17:19, Ilya Maximets wrote:
> On 2/7/24 03:21, Lim, Derrick wrote:
>> Hi Ilya Maximets,
>>
>> From the tcpdump, with or without the rewrite, the link-local address was
>> used.
>>
>> ===
>> $ ovs-tcpdump -nn -i exit_p0
>> 11:10:26.32
On 2/7/24 03:21, Lim, Derrick wrote:
> Hi Ilya Maximets,
>
> From the tcpdump, with or without the rewrite, the link-local address was
> used.
>
> ===
> $ ovs-tcpdump -nn -i exit_p0
> 11:10:26.323938 IP6 fe80::dc03:37ff:fee2:1fef.51513 >
> 2403:400:31da:::18:
try.
OVS 2.17 is not supposed to work with DPDK 22.11, it's supposed to work with
21.11.
See the compatibility table here:
https://docs.openvswitch.org/en/latest/faq/releases/
Though it's hard to tell if DPDK version is anyhow related to the issue.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Description
===
In multiple versions of Open vSwitch, if OpenFlow rules on a switch
contain a match on a Target Address (nd_target) of Neighbor Discovery
IPv6 packets (Neighbor Solicitation or Neighbor Advertisement) without
also matching on ICMPv6 Code (icmp_code or icmpv6_code) field
Description
===
Multiple versions of Open vSwitch are vulnerable to crafted Geneve
packets causing invalid memory accesses and potential denial of service.
Triggering the vulnerability requires that Open vSwitch has flow hardware
offload with Linux TC flower enabled
E lock
> has been canceled.
>
> May I still need a RECURSIVE lock for rstp?
Thanks for the report!
Indeed, the mutex has to be recursive in the current version of the code
for the same reason STP mutex is recursive.
I can prepare a patch to fix this.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 2/2/24 08:58, Lim, Derrick via discuss wrote:
> Hi Ilya Maximets,
>
>> The rules look mostly fine. I think the main problem you have is priority.
>> Default priority for OF rules (if not specified) is 32768, so your new rules
>> with priority 50 are too low in a prior
indicates that rebalancing will be performed as soon as possible.
Your suggested change will make the value positive, but it will no longer
be correct in this case. We could print out a zero, I guess, instead of
a negative value, but, I think, the negative value is somewhat usefu
al occurrences of similar statistics
issues during flow dumps. Can you reproduce the issue on the latest
v2.17.8 release? 2.17.2 is fairly old and coent contain many important
bug fixes. Newer releases like 3.1.2+ also have enhanced logging
around statistics mishaps, so they are easier to debug.
with 'deadlock avoided' or something like that.
From the commit I linked it's clear why it's not happening if the max-rate
is specified. The code just doesn't go that route.
To fix the issue, we need to have a lockless version of netdev_linux_get_speed()
and call it directly from the QoS functions wit
On 1/29/24 10:23, Lim, Derrick wrote:
> Hi Ilya Maximets,
>
> I did some further testing on my end. Just to make sure it's an address
> family issue, I tried to configure all VXLAN interfaces with IPv6, but
> I ran into an issue with the source IP address selection.
>
> I sp
On 1/26/24 09:37, Lim, Derrick wrote:
> Hi Ilya Maximets,
>
> Thank you for explanation. I've create the two bridges, but the packet
> seems to be dropped looking at the `ovs-appctl dpctl/dump-flows` output.
> I didn’t receive it on the remote host either.
>
> In my setup, t
The br-phy should have an IP address from the
tunnel subnet, so after encapsulation the packet is getting routed to br-phy.
In br-phy the packet can be matched with OF rules and actions can be executed
before sending it to the egress interface.
Best regards, Ilya Maximets.
__
the flow configurations lead to changes in ovsdb. Is
> this approach realistic?
Hi, Zekeriya.
OpenFlow rules are not stored in the database, so you can't do that.
What you can do is to use OpenFlow monitor instead. ovs-ofctl has
a correcponding command.
Best regards, Ilya Maximets.
0, the second flow will be
successfully installed with the fix applied.
>
>
>
> -邮件原件-
> 发件人: Ilya Maximets
> 发送时间: 2024年1月16日, 星期二 20:53
> 收件人: David Zhang (张同剑)-浪潮信息 ; b...@openvswitch.org
> 抄送: i.maxim...@ovn.org
> 主题: Re: [ovs-discuss] dpif-netlink: ovs flow
> Thanks & Regards,
> RS
>
> On Mon, Jan 15, 2024 at 10:23 PM Ilya Maximets <mailto:i.maxim...@ovn.org>> wrote:
>
> On 1/15/24 21:05, Reshma Sreekumar via discuss wrote:
> > I see..thanks for the explanation. My use-case is to have a traffic
> red
8f:73:57,dst=fa:16:3e:59:e8:49)),set(ipv4(dst=10.147.7.12,ttl=62)),pop_vlan,ct(zone=1),recirc(0x13b6c8)
>
> ovs version: 2.15.2
Note: 2.15 is a fairly old release now and it is no longer supported.
You should upgrade to at least 2.17.
Best regards, Ilya Maximets.
__
ype.
I suppose, the traffic will enter OVS after IFB. So, you'll have your
veth1 (ingress qdisc) --> ifb (egress qdisc) --> OVS. Should be fine
if you're going to redirect all the traffic to ifb.
Let us know if that works.
Best regards, Ilya Maximets.
__
ld use the ingress_policing_* configuration options
instead. If you have some other use case for external ingress qdiscs,
OVS will have to be changed to be aware of it.
Best regards, Ilya Maximets.
>
> Regards,
> RS
>
> On Thu, Jan 11, 2024 at 5:42 PM Ilya Maximets <mailto:
(trying to re-send as gmail decided to not deliver the previous email)
On 1/11/24 17:38, Ilya Maximets wrote:
> On 1/11/24 17:25, Reshma Sreekumar via discuss wrote:
>> Hello all,
>>
>> An ingress qdisc configured on a port that is enslaved into an OpenvSwitch
>> bridge
cted.
If you want OVS to avoid removing qdiscs configured externally, you
may configure a "linux-noop" QoS class for this interface. E.g.:
$ ovs-vsctl set port veth1 qos=@myqos -- --id=@myqos create qos type=linux-noop
Best regards, Ilya Maximets.
>
> *OVS version :*
>
> ov
On 1/4/24 07:35, Eli Britstein via discuss wrote:
>
>
>> -Original Message-----
>> From: Ilya Maximets
>> Sent: Wednesday, 3 January 2024 19:12
>> To: Eli Britstein ; ovs-discuss@openvswitch.org
>> Cc: Maor Dickman ; i.maxim...@ovn.org
>> Subject:
nce the
logic was introduced, so there might be problems with this
approach that I'm not aware of.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
is a
Netronome extension NTRT_SELECTION_METHOD. See more details here:
https://raw.githubusercontent.com/openvswitch/ovs/master/Documentation/group-selection-method-property.txt
Best regards, Ilya Maximets.
> Here is a set of commands to show what I'm seeing in OVS (initial group
> i
On 11/1/23 17:05, Chuck Lever III wrote:
>
>
>> On Nov 1, 2023, at 3:18 AM, Ilya Maximets wrote:
>>
>> On 10/31/23 22:00, Chuck Lever III via discuss wrote:
>>> Hi-
>>>
>>> I recently made some changes to tmpfs/shmemfs and someone has reported
278ea690/utilities/ovs-lib.in#L632
Also, ovsdb-server process is using the most basic version of a
temporary file in its runtime, created by tmpfile(3). But this
process is not even restarted by the ovs-vswitchd restart.
HTH.
Best regards, Ilya Maximets.
_
mode=active-backup miimon=100 use_carrier=0''? Or
> more parameter configuration is required in
> command"# ovs-vsctl add-bond br-oam bond1 eth1 eth5 trunk=3932,3933" ?
By default the bonding mode is active-backup, but the default failure
detection mode is carrier, so you'll need to
On 10/26/23 14:05, Odintsov Vladislav wrote:
> Hi,
>
>> On 19 Oct 2023, at 17:06, Vladislav Odintsov via discuss
>> wrote:
>>
>>
>>
>>> On 18 Oct 2023, at 18:43, Ilya Maximets via discuss
>>> wrote:
>>>
>>> On 10/18/23
ovs|1|vsctl|INFO|Called as /usr/bin/ovs-vsctl del-port br-oam bond1
OVS is not doing that on its own. You need to find what is calling
this command in order to fix the problem. Likely candidates are
network-scripts, NetworkManager or something similar.
Best regards, Ilya
On 10/18/23 17:14, Vladislav Odintsov wrote:
> Hi Ilya, Terry,
>
>> On 7 Mar 2023, at 14:03, Ilya Maximets wrote:
>>
>> On 3/7/23 00:15, Vladislav Odintsov wrote:
>>> Hi Ilya,
>>>
>>> I’m wondering whether there are possible configuration p
On 10/18/23 16:24, Vladislav Odintsov wrote:
> Hi Ilya,
>
> thanks for your response!
>
>> On 18 Oct 2023, at 15:59, Ilya Maximets via discuss
>> wrote:
>>
>> On 10/17/23 16:30, Vladislav Odintsov via discuss wrote:
>>> Hi,
>>>
>>>
On 10/17/23 16:30, Vladislav Odintsov via discuss wrote:
> Hi,
>
> I’m testing OVS hardware offload with tc flower with Mellanox/NVidia
> ConnectX-6 Dx smartnic and see next warning in ovs-vswitchd log:
>
> 2023-10-17T14:23:15.116Z|00386|tc(handler20)|WARN|Kernel flower
> acknowledgment does
e kernel. And it makes
some sense
because you're restarting the network. Does this bond1 interface exist after
the network
restart? What creates it back? network-scripts? If so, you should check these
network-scripts. And the port-add command should be somewhere in the same
network scripts.
a
system you have. You might have some other configuration issues.
>
> In addition:
> [9] ovs-vsctl show
> [10] OVSDB dump
> [11] pmd-stats-show
> [12] bond info with ovs-appctl
>
> For compute nodes, I use Rocky Linux 8.5, Open vSwitch 2.15.5, and DPDK
> 20.11.1.
F
luster12-b kernel: [340557.486891][
> T2447] bond1 (unregistering): Released all slaves/
IIUC, the 'bond1' is some sort of a kernel bonding device configured
outside of OVS. And it is getting removed.
When you restart the network, the system will execute whatever network
configuration is in your
On 10/13/23 14:22, Xuo Guoto via discuss wrote:
> --- Original Message ---
> On Friday, October 13th, 2023 at 4:51 PM, Ilya Maximets
> wrote:
>
>> I'd suggest you disable the lacp-fallback-ab, so the bond doesn't
>> fall back to active-backup mode on failure
On 10/13/23 12:55, Xuo Guoto wrote:
>
> --- Original Message ---
> On Friday, October 13th, 2023 at 3:51 PM, Ilya Maximets
> wrote:
>
> Thanks again for taking time to answer my questions!
>
>
>> Here is your problem. The bond is in active-backup mode
On 10/13/23 07:22, Xuo Guoto via discuss wrote:
> --- Original Message ---
> On Thursday, October 12th, 2023 at 9:03 PM, Ilya Maximets
> wrote:
>
> Thanks again for the detailed reply!
>
>> If you want to preserve these, you'll need to re-add them manually
On 10/12/23 15:39, Xuo Guoto via discuss wrote:
> Thanks for your reply!
>
> --- Original Message ---
> On Thursday, October 12th, 2023 at 6:48 PM, Ilya Maximets
> wrote:
>
>
>> You currently have port vnet75 with an interface vnet75, and the
>>
tes two interfaces vnet75 and vnet78, and adds them into
a port. But interfaces vnet75 and vnet78 already exist, so the
command fails. The 'may-exist' flag only check for existence of
the port, not interfaces in it.
You currently have port vnet75 with an interface vnet75, and the
port vnet78 with interface vnet78. But you want a port bond0
with interfaces vnet75 and vnet78. In order to achieve that you
need to remove ports vnet75 and vnet78 first, and then create
a port bond0.
HTH
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
newer versions of DPDK.
Also, representor syntax changed a few times in the past, so your
script may not work with older versions of DPDK.
If you can't build DPDK on the board itself, cross-compiling may be
an option:
https://doc.dpdk.org/guides/platform/bluefield.html
Also OVS 2.14 is likely a poor ch
null,{"Chassis_Private":{"94e607a0-9e1a-4ca4-9e26-b1cbdcdf362a":{"external_ids":["map",[["neutron:ovn-metadata-sb-cfg","1078278"]]]}},"_date":1695209448827,"_is_diff":true}],"term":9866,"index":*8583427*}/
Leaving directory '/opt/ovs-2.17.7'
> make: *** [Makefile:3079: all] Error 2
> ```
>
> Asking google did not help at all :(
> Did anyone encounter such errors?
Nvidia is using their closed-source versions of OVS and DPDK, so the
versions y
turn the ACL into multiple ACLs with
positive matches instead, if possible. E.g. by using an explicit
'allow' ACL for these CIDRs and a lower priority catch-all 'deny'.
The issue was mostly addressed in OVN 23.06 by the following commit:
https://github.com/ovn-org/ovn/commit/422ab29e76b5d5bf3865fc743434cb958ce20cc8
So,
nstall --root-cmd sudo --remove debian/control
# dpkg-checkbuilddeps
# make debian-deb
That should end up with a pack of debian packages.
>
>
> Regards
>
> Laurent
>
>
>
>
> Internal
> -Message d'origine-
> De : Ilya Maximets
> Envoyé : vendred
t;
>
>
> Internal
> -Message d'origine-
> De : Ilya Maximets
> Envoyé : vendredi 8 septembre 2023 14:15
> À : Eelco Chaudron ; Laurent Coloby
>
> Cc : i.maxim...@ovn.org; b...@openvswitch.org
> Objet : Re: [ovs-discuss] open vswit
ion, you name the bridge in libvirt, ovsbr. But your ovs show
> command does not have that bridge created.
+1
That will become an issue once you fix the permissions.
>
>>
>> Regards
>>
>>
>>
>>
>> Internal
>> -Message d'origine-
>>
On 9/7/23 16:38, Michal Prívozník via discuss wrote:
> On 9/6/23 15:26, Laurent Coloby via discuss wrote:
>> Hello support
>>
>> I'm blocked on a basic issue
>>
>> I use libvirt / KVM with unbutu
>>
>>
>> I just want to launch a virtual Machine with a connection to OVS
>>
>> With command virsh
On 8/25/23 15:55, Ilya Maximets wrote:
> On 8/25/23 10:08, Sangeetha Elumalai via discuss wrote:
>> Hi,
>>
>> Thank you for your quick response and patch.
>> The "2560" issue was fixed by applying the patch.
>> Still facing the issue for "1088&qu
olution might be to stop the time with a time warping mechanism, so
revalidators will not expire datapath flows. If one of you want to fix
that, let me know and feel free to submit a patch. Otherwise, I can take
a stab at fixing this later.
Best regards, Ilya Maximets.
>
> 0:
> ht
h/20230823215705.1786348-1-i.maxim...@ovn.org/
Han pointed me to this thread, as it seems like the issue you're facing
is practically the same.
I agree though that there is a potential for even further improvement as at
least there should be a way to not duplicate all the chassis in each group.
But
On 8/23/23 19:58, Roberto Bartzen Acosta wrote:
> Hi Ilya,
>
> Em qua., 23 de ago. de 2023 às 13:45, Ilya Maximets <mailto:i.maxim...@ovn.org>> escreveu:
>
> On 8/23/23 07:59, Roberto Bartzen Acosta wrote:
> > Hi Ilya,
> >
> &g
eling-related Commands' section in [0].
Note, however, that this route will only be stored in memory, so
you will need to re-add it back on OVS restart.
Best regards, Ilya Maximets.
>
> *[0]*
> https://docs.openvswitch.org/en/latest/howto/userspace-tunneling/
> <https://docs.openvswitch.org/e
tHub ?
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
will open the kernel datapath and set flags to it in the process.
> In your particular case, these flags change the way upcalls are
> delivered to ovs-vswitchd, so no traffic can go to userspace
> afterwards and no new flows will be installed to a datapath as
> a result, bec
is not
safe. Use ovs-appctl dpctl/* commands to get the same information
via ovs-vswitchd instead. Or at least make sure that the version
of ovs-dpctl is exactly the same as version of ovs-vswitchd.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Nit: And there is no much sense in having 10 queues and only 3
cores in pmd-cpu-mask. Also, iperf is single threaded by default,
so only one queue will likely be utilized anyway.
Bets regards, Ilya Maximets.
> type=dpdkvhostuser
>
> QEMU command used to start VM
>
> $
not able to see tunnel ports,
they should be visible like any other ports. But encapsulated packets
usually have specific UDP destination port numbers, so you should be
able to create OpenFlow rules that match on them, in case you just need
to forward these packets without d
that?
The pypi package is maintained by OpenStack folks mostly
for their own use. But, I guess, it should be possible
to update to some newer stable release.
Terry, what do you think?
Best regards, Ilya Maximets.
>
> [1] https://pypi.org/project/ovs/#histor
from OVS sources. You should be
> able to run OVN built this way with your OVS 2.17.7 without any
> issues.
>
> One inconvenience though is that, unfortunately, release archives
> on GitHub do not include submodules (GitHub doesn't support that).
> So, you'll need to check it out yourself.
>
> Best regards, Ilya Maximets.
>
>>
>> Thanks in advance for your help,
>> Joe
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
4ffacd27.
OVN only uses some libraries from OVS sources. You should be
able to run OVN built this way with your OVS 2.17.7 without any
issues.
One inconvenience though is that, unfortunately, release archives
on GitHub do not include submodules (GitHub doesn't support that).
So, you'll need to c
ader-only find Logical_Switch \
name=a_b461d3e2_621c_43f4_8d7c_e39c13bcba08_ls_bca4b75e_9b21_4454_98a3_e490feecae9f
\
ports{\>}1191229a-6878-4dfc-b07a-47e6e2a4dcfe
Following command should check if two ports are there:
ovn-nbctl --no-leader-only find Logical_Switch \
name=a_b46
was hybrid):
https://www.openvswitch.org/support/ovscon2022/
And here is a CFP for this year (will be virtual):
https://mail.openvswitch.org/pipermail/ovs-announce/2023-July/000324.html
Best regards, Ilya Maximets.
> and not a Openflow specific one. Obviously, it needs to be a network-related
> conf
t;
> ovs-vsctl add-port br0 gre1 -- set interface gre1 type=gre
> options:remote_ip=192.168.10.6 options:key=3
>
> but this also didn’t change things and the chosen action for the packets was
> to drop them instead, of executing my custom action
ction into
OpenFlow. If you're writing your own controller, you should be able to
create a raw OpenFlow request with any action you want.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
gt;> thank you for the detailed reply
>>>
>>> On Tue, May 23, 2023 at 05:25:49PM +0200, Ilya Maximets wrote:
>>>> On 5/23/23 15:59, Felix Hüttner via discuss wrote:
>>>>> Hi everyone,
>>>>
>>>> Hi, Felix.
>>>>
>
You should be able to fix udev issue with more udev.
For quite a few years now it should support predictable device names
based on BIOS config or PCI location of your actual NIC:
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Best regards, Ilya Maximets.
o something during
> COVERAGE_DEFINE() that would be like:
>
> COVERAGE_DEFINE(ctr, "description")
>
> and then we can generate documentation from the COVERAGE_DEFINE()s as
> well as querying for it with an ovs-appctl command.
>
> That might be trying to be too
On 6/13/23 15:55, Vašek Šraier wrote:
> Hi,
>
> On 2023-06-12 18:40, Ilya Maximets wrote:
>> Flushing datapath flows underneath running ovs-vswitchd process
>> may cause all kind of weird behaviour. So, the del-flows as well as
>> most of the other ovs-dpctl comman
1 - 100 of 275 matches
Mail list logo
