Gavin, I think it's very useful information, thank you!
I didn't read about issues related to using the common zone before.
Generally, we use dnat_and_snat rule when allocating FIP to the VMs, but I
didn't have time to try it with the LB scheme in common zone
Regards,
Ildar, network engineer
On
Ildar/Numan,
If you are using HWOL on a smart NIC (CX6 and CX7 ) I had run into an
issue with dnat_and_snat offloading in one direction only (OVN central
23.09.0 and OVN controller 23.09.0)
I worked with the Nvidia team on this problem and the summary was as follows:
Initially there was an offlo
Numan, thanks for clarification, I didn't know that both approaches use OVS
conntrack the same way
Now I think we'll do that.
On Wed, Jul 24, 2024 at 6:28 PM Numan Siddique wrote:
> On Wed, Jul 24, 2024 at 11:15 AM Ildar Isangulov via discuss
> wrote:
> >
> > Hi, Justin! Sorry, didn't notice y
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
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 <
ildarvildanovich...@gmail.com> wrote:
> Hi Numan, thanks for your reply, here more details as you requested
>
> This is a structure of NAT table in t
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 :
ex
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
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
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 i
On Wed, May 08, 2019 at 02:54:58PM -0600, Carl Baldwin wrote:
> Thanks for your quick response. Your assessment makes sense to me. For
> IPv4, I don't think 0 would be a valid protocol number but for IPv6 it
> would mean that the hop-by-hop options are present.
For IPv6, OVS does not literally use
Ben,
Thanks for your quick response. Your assessment makes sense to me. For
IPv4, I don't think 0 would be a valid protocol number but for IPv6 it
would mean that the hop-by-hop options are present.
What do you think about the extra no-op actions in the datapath
actions when I set the protocol to
I investigated this a little bit by putting the following in a file
named 'flows':
table=0 ip,in_port=4,dl_dst=a6:c1:a7:15:a4:3d,nw_dst=10.39.176.4,priority=3100,
actions=resubmit(,25)
table=25, ip,vlan_tci=0x1000/0x1000,nw_dst=10.39.176.4, priority=3100,
actions=set_field:00:00:5e:00:01:01->eth
Greetings,
I have been using ofproto/trace to verify the actions taken on various
packets through an OVS bridge. My methodology is basically to specify
the action in br_flow format to ovs-appctl ofproto/trace and then
comparing the datapath actions line with expected actions. I ran into
an interes
13 matches
Mail list logo