On Fri, 19 Apr 2024 12:31:33 +0800 Jun Gu wrote:
> From: "jun.gu"
>
> Ensure that the provided netdev name is not one of its aliases to
> prevent unnecessary creation and destruction of the vport by
> ovs-vswitchd.
>
> Signed-off-by: jun.gu
> Acked-by: Eelco Chaudron
I said: When you
Hi All:
Part of upgrading OVN north south gateway to the new 5.4 kernel , VMs
connectivity is lost when setting chassis for provider network lrp to this
new gateway. For interconnection gateways and hypervisors its not an issue/
lrp
_uuid : 387a735d-fc11-4e90-8655-07785aa024af
On Fri, Apr 19, 2024 at 7:09 AM Ales Musil wrote:
> The current packet injection loses ct_state in the process. When
> the ct_state is lost we might commit to DNAT zone and perform
> zero SNAT after the packet injection. This causes the first session
> to be wrong as the reply packets are not
When the logical router is disabled it is not populated in the datapaths
and is not internally available to I-P engine in the hmap. This could
lead to a crash during I-P processing:
To fix that make sure we process incrementally only LR that are enabled.
Reported-at:
On Thu, Apr 18, 2024 at 11:20 PM shy liu wrote:
> >
> >
> >
> > On Tue, Apr 16, 2024 at 1:22 AM wrote:
> >>
> >> From: shylou
> >>
> >> DHCP for VM fails when removing default security group rules
> >> using a CMS like Neutron ML2/OVN [1]. This is because DHCP
> >> requests from VMs may be
All informations required for checksum offloading can be deduced by
already tracked dp_packet l3_ofs, l4_ofs, inner_l3_ofs and inner_l4_ofs
fields.
Remove DPDK specific l[2-4]_len from generic OVS code.
netdev-dpdk code then fills mbuf specifics step by step:
- outer_l2_len and outer_l3_len are
In a typical setup like:
guest A <-virtio-> OVS A <-vxlan-> OVS B <-virtio-> guest B
TSO packets from guest A are segmented against the OVS A physical port
mtu adjusted by the vxlan tunnel header size, regardless of guest A
interface mtu.
As an example, let's say guest A and guest B mtu are set
Replace check on th == NULL with an assert() because dp_packet_l4(pkt)
is priorly used to compute (outer) L3 length.
Besides, filling l4_len and tso_segsz only matters to TSO, so there is
no need to check for other L4 checksum offloading requests.
Signed-off-by: David Marchand
---
If outer checksum is not supported and OVS already set L3/L4 outer
checksums in the packet, no outer mark should be left in ol_flags
(as it confuses some driver, like net/ixgbe).
l2_len must be adjusted to account for the tunnel header.
Fixes: 084c8087292c ("userspace: Support VXLAN and GENEVE
The outer checksum offloading API in DPDK is ambiguous and was
implemented by Intel folks in their drivers with the assumption that
any outer offloading always goes with an inner offloading request.
With net/i40e and net/ice drivers, in the case of encapsulating a ARP
packet in a vxlan tunnel
Same as the commit 6f93d8e62f13 ("netdev-dpdk: Disable outer UDP checksum
offload for ice/i40e driver."), disable outer UDP checksum and related
offloads for net/iavf.
Fixes: 084c8087292c ("userspace: Support VXLAN and GENEVE TSO.")
Signed-off-by: David Marchand
---
Note:
- DPDK (in progress)
This change fixes bug that breaks ability of machines from external
networks, to communicate with machines in SNATed networks (specifically
when using a Distributed router).
Currently when a machine (S1) on an external network tries to talk
over TCP with a machine (A1) in a network that has
This change adds a new action 'ct_commit_to_zone' that enables users to commit
the flow into a specific zone in the connection tracker.
A new feature flag, OVN_FEATURE_CT_COMMIT_TO_ZONE, is also included to avoid
issues during upgrade in case the northd is upgraded to a version that supports
this
On 4/19/24 13:14, Ales Musil wrote:
> The local_ip should be present for chassis with single encap whenever
> we configure its interface in OvS. Not having the local_ip can lead to
> traffic being dropped on the other side of tunnel because the source
> IP might be different, this is more likely
The local_ip should be present for chassis with single encap whenever
we configure its interface in OvS. Not having the local_ip can lead to
traffic being dropped on the other side of tunnel because the source
IP might be different, this is more likely to happen in pure IPv6
deployments.
Remove
The current packet injection loses ct_state in the process. When
the ct_state is lost we might commit to DNAT zone and perform
zero SNAT after the packet injection. This causes the first session
to be wrong as the reply packets are not unDNATted.
Instead of re-injecting the packet back into the
On 4/19/24 10:50, Ales Musil wrote:
> There are some improvements that are needed for further work on OVN
> side. Most notably the commits mentioned below:
>
> a0df9c85def0 ("netdev-dummy: Add local route entries for IP addresses.")
> c67de08f1d82 ("dpif-netdev: Increase MAX_RECIRC_DEPTH to 8.")
There are some improvements that are needed for further work on OVN
side. Most notably the commits mentioned below:
a0df9c85def0 ("netdev-dummy: Add local route entries for IP addresses.")
c67de08f1d82 ("dpif-netdev: Increase MAX_RECIRC_DEPTH to 8.")
c560f6ca3257 ("ofproto-dpif-xlate: Fix
On 4/4/24 20:41, Vladislav Odintsov wrote:
> Commit [1] introduced a "vxlan mode" concept. It brought a limitation
> for available tunnel IDs because of lack of space in VXLAN VNI.
> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
> and 2047 logical switch ports per
On 4/4/24 21:23, Ihar Hrachyshka wrote:
> On Thu, Apr 4, 2024 at 6:06 AM Dumitru Ceara wrote:
>
>> On 4/3/24 22:05, Vladislav Odintsov wrote:
>>> re-sending email because ovs list rejected previous its content for some
>> reason:
>>>
>>> Hi Ihar,
>>>
>>
>> Hi Vladislav, Ihar,
>>
>>> thanks for
On 3/28/24 13:28, Priyankar Jain wrote:
> Issue:
> Upon updating the network_name option of localnet port from one physical
> bridge to another, ovn-controller fails to cleanup the peer localnet
> patch port from the old bridge and ends up creating a duplicate peer
> localnet patch port which
On 3/27/24 09:43, Felix Huettner via dev wrote:
> In most cases IPv4 packets are routed only over other IPv4 networks and
> IPv6 packets are routed only over IPv6 networks. However there is no
> interent reason for this limitation. Routing IPv4 packets over IPv6
> networks just requires the router
Ensure that the provided netdev name is not one of its aliases to
prevent unnecessary creation and destruction of the vport by
ovs-vswitchd.
Signed-off-by: Jun Gu
Acked-by: Eelco Chaudron
---
net/openvswitch/vport-netdev.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
23 matches
Mail list logo
