, trace can only mimic behavior of the connection
tracking, but it doesn't use the actual conntrack states in the datapath.
The main reason is that passing packets through connection tracking will change
the state of the connection tracker, potentially breaking the real traffic flo
er ports from br-int
but ont he other node, the traffic will go to a tunnel, then kernel will
route the encapsulated packet to br-ext, so it will be sent over eth0.
On the other side the encapsulated packet will arrive on eth0, go to
br-ext port, kernel will decapsulate it and inject into br-int
On 10/1/24 12:56, Ilya Maximets via discuss wrote:
> On 10/1/24 10:44, Adrián Moreno via discuss wrote:
>> On Mon, Sep 30, 2024 at 01:52:13PM GMT, Harald Albrecht via discuss wrote:
>>> My "quest" is to discover the topology of OVS switches and their netdev
>>&
without those
non-satisfied dependencies and we can move on with our lives... But this
requires a lot of considerations and discussion with QEMU / virtio maintainers.
I'll start the thread on qemu-devel to check if there are issues with such
a solution
a dot.
See some more details and examples here:
https://docs.openvswitch.org/en/latest/internals/contributing/coding-style/#comments
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 9/26/24 18:59, Sri kor via discuss wrote:
>
>
> @Dumitru Ceara and @Ilya Maximets,
> Any thoughts on this?
>
> Thanks,
> Srini
>
> On Fri, Sep 20, 2024 at 12:27 AM Sri kor <mailto:esrik...@gmail.com>> wrote:
>
> In between, we are usi
On 10/1/24 10:44, Adrián Moreno via discuss wrote:
> On Mon, Sep 30, 2024 at 01:52:13PM GMT, Harald Albrecht via discuss wrote:
>> My "quest" is to discover the topology of OVS switches and their netdev ports
>> to provide some (albeit limited) OVS-related information to users of the
>> Ghostwire L
t;. Relay will accept connections on that one
(should likely be a passive connection, e.g. ptcp: or pssl:).
The "source" is from where this relay will get the data, i.e. the
source of the data, the address of the main database (should likely
be an active connection, e.g tcp: or ssl:).
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
r to better track the rate of incoming flow modifications,
you may look at coverage counters instead.
Stats of the OVS threads also do nott indicate any high load on the
main ovs-vswitchd thread that is responsible for the flow mods.
Revalidator threads also do not seem to be particularly busy.
olution is for DPDK project to test drivers it ships, but
maybe having a knob that turns off all the offloading per interface would be
useful. Maybe two knobs - one for all the tunnel offload and one for all the
other offload. But I don't think going more granular makes sense, as we
/etc/hosts has a strict format that should be followed.
So, yes, this needs to be fixed on the CI/CD side.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 9/16/24 17:59, Adrián Moreno wrote:
> On Mon, Sep 02, 2024 at 10:14:34AM GMT, Eelco Chaudron via discuss wrote:
>> Hi,
>>
>> I’m not an expert in this area, but I can see the metadata is explicitly
>> cleared when traffic goes over a patch port.
>>
>> https://github.com/openvswitch/ovs/blob/0051
t;,
> remote_state=down, state=down}
>
> for both of my nodes. I do think the tunnel is working since our upper
> layer
> who uses the OVS tunnel works. But why are the states all down and it's
> showing "No Diagnostic"?
Hard to tell, but it seems like
static strongSwan config instead, updating it when necessary.
Best regards, Ilya Maximets.
>
> On Fri, Aug 16, 2024 at 12:03 AM Jim C <mailto:jimc84...@gmail.com>> wrote:
>
> Actually, it's probably due to this on that strongSwan page: *Note: Some
> distribution
le BFD (check_tnl_key is not necessary, but recommended):
ovs-vsctl set interface bfd:enable=true bfd:check_tnl_key=true
Then you may monitor bfd_status column in the interface table for the current
state of the tunnel. It will also show up in the ovs-vsctl show. More detailed
status is also available in 'ovs-appctl bfd/show'.
More info in ovs-vswitchd.conf.db(5).
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 5/16/24 22:29, Ilya Maximets wrote:
> On 5/16/24 19:33, Jim C via discuss wrote:
>> Hi,
>>
>> I'm looking into this IPSec tutorial
>> (https://docs.openvswitch.org/en/latest/tutorials/ipsec/).
>> I wonder if there is an option for us to choose the encrypti
or unusual setups.
Best regards, Ilya Maximets.
>
> Thanks.
>
> On Wed, Aug 7, 2024 at 2:27 PM Ilya Maximets <mailto:i.maxim...@ovn.org>> wrote:
>
> On 8/7/24 23:10, Jim C wrote:
> > Actually, we may not have the right path. Instead of /etc/strongsw
ile on the disk, open
it and change the self.CHARON_CONF variable to a different location.
>
> Also, by `by ovs-monitor-ipsec daemon when it starts`, is it when we run
> `systemctl start openvswitch-ipsec`?
Yes.
>
> On Wed, Aug 7, 2024 at 12:03 PM Ilya Maximets <mailto:i.maxi
at's the case, does it mean that we must install OVS after strongSwan is
> installed?
>
> Thanks.
>
> On Wed, Aug 7, 2024 at 9:14 AM Ilya Maximets <mailto:i.maxim...@ovn.org>> wrote:
>
> On 8/7/24 09:11, Jim C wrote:
> > Thanks Ilya, but we s
those packages. Otherwise, OVS IPsec package would not be usable
out of the box.
If you're installing strongSwan from a third party source, you'll need to modify
OVS RPM spec file and systemd unit files and re-build the RPMs from source.
There is no way to disable dependencies i
and find out why it is not there.
Best regards, Ilya Maximets.
> *
>
> We are using:
> strongSwan 5.10
> Rocky (RHEL) Linux
>
> We do hope to get rid of the libreswan dependency tho. But for now, we can't
> switch to using strongSwan.
>
> Thanks.
>
>
support IP options. It doesn't
parse them and doesn't act on them. But it should allow packets
with options to pass through.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
l stop-ovs-ipsec
>
> [Install]
> WantedBy=multi-user.target
>
> It seems it's using libreswan. How can we switch to using strongSwan instead?
If you have strongSwan installed, you should be able to just
replace --ike-daemon=libreswan with --ike
On 7/23/24 11:04, Grigorii Nazarov wrote:
> On 7/3/24 3:22 PM, Grigorii Nazarov wrote:
>> On Tuesday, July 2, 2024 2:48:35 PM GMT+3 Ilya Maximets wrote:
>>> On 7/2/24 12:01, Grigorii Nazarov via discuss wrote:
>>>> The test was run on unmod
I
can't find it...)
One way to do that is to create the controller record for the main
management controller in the database from ovs-vswitchd, if it doesn't
already exist, so users can change the values in the database record,
if they need to.
Best regards, Ilya Maximets.
>
> 1:
ration not permitted
System tests need to be ran as root, in general.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 6/25/24 13:12, Ales Musil wrote:
>
>
> On Tue, Jun 25, 2024 at 1:02 PM Ilya Maximets <mailto:i.maxim...@ovn.org>> wrote:
>
> On 6/24/24 17:52, Ales Musil via discuss wrote:
> > Hi,
> >
> > I would like to propose a universal coding
REG_DHCP_RELAY_DIP_IPV4 " = "
+ "ip4.dst;"
+ " " REGBIT_DHCP_RELAY_RESP_CHK
+ " = dhcp_relay_resp_chk(%s, %s); "
+ "next; /* DHCP_RELAY_RESP */",
+ op->lrp_networks.ipv4_addrs[0].addr_s, server_ip_str);
In general, northd code is not easy to read, but I really don't like
what clang-format does with it in many places.
I only checked two OVN files, so maybe there is more.
Also, have you tried GNU indent referenced in the coding style document?
It is also far from being perfect though.
Bets regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
d-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
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!
>
em occurs because of the tunnel_key update 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
ev2=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://ma
yphers 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:
>
n of OpenSSL. 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 mai
nection tracking in 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 straightfor
don'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, Ily
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 from 3.1
s,
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
that OVS restart fixes the issue may 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
plicit configuration 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
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
connection per event 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 so
ve this
one will 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 li
de. I would 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
___
f 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
route 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
0-25-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
ghts on this?
A workaround for this 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 rec
g=true&retina=true
> +.. image::
> https://ci.appveyor.com/api/projects/status/github/openvswitch/ovs?branch=main&svg=true&retina=true
> :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
is using the schema 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
o different followers. They'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 caus
ssue, 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
on? 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
Default
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
iscs from 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 regar
f5
Could you try 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, 2
27;ovs-vsctl 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:
1.6 you could 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, I
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 bei
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 (other_config:hw-offloa
d.), RECURSIVE 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
t 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.
utex for a second time. That fails
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
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.
>
>
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 set
r bridge (br-phy). 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
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.
!= 20, 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
e.
>
> 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
=fa:16:3e: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.
QoS type.
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.
__
should 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 <ma
(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:
ds.
The action commit code also changed quite a bit since 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
s.
If you still want to use the 'selection_method' property, it 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.
> Her
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
455eb1adcfda8d8278ea690/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.
__
uot;
>
> Would bond1 in solution B> work in the same way as bond1 in solution A>
> , Especially the work of eth1ð5
> as ' BONDING_MODULE_OPTS='mode=active-backup miimon=100 use_carrier=0''? Or
> more parameter configuration is required in
> comma
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
tl:
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 Maxime
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 no
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 scr
2.6Gbps seems like a small number for the type of 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.
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
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 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 manual
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
>>
'port' named
bond0, creates 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
figure out how to build 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
1 - 100 of 307 matches
Mail list logo
