Paolo Valerio writes:
> Adrian Moreno via discuss writes:
>
>> Hi Gavin
>>
>> On 4/18/24 02:38, Gavin McKee via discuss wrote:
>>> This is an example.
>>>
>>> Again the TCP 3 handshake completes , but the next packet fails to NAT
>>> and goes out onto the physical network using the private
Adrian Moreno via discuss writes:
> Hi Gavin
>
> On 4/18/24 02:38, Gavin McKee via discuss wrote:
>> This is an example.
>>
>> Again the TCP 3 handshake completes , but the next packet fails to NAT
>> and goes out onto the physical network using the private address . An
>> example of this is
YunTang Hsu via discuss writes:
> Hi,
>
> I have a kind cluster with Antrea installed. Since I want to use the conntrack
> event listener to track the creation/termination of connections, I installed
> conntrack CLI in one of Antrea-agen pods.
> When I used command “conntrack -E” to listen to
Lazuardi Nasution writes:
> Hi Paolo,
>
> Should we combine this patch too?
>
> https://patchwork.ozlabs.org/project/openvswitch/patch/
> 168192964823.4031872.3228556334798413886.st...@fed.void/
>
Hi,
no, it basically does the same thing in a slightly different way
reducing the need for
"Plato, Michael" writes:
> Hi Paolo,
> I installed the patch for 2.17 on april 6th in our test environment and can
> confirm that it works. We haven't had any crashes since then. Many thanks for
> the quick solution!
>
Hi Micheal,
Nice! That's helpful. Thanks for testing it.
Paolo
> Best
Lazuardi Nasution writes:
> Hi Paolo,
>
> I'm interested in your statement of "expired connections (but not yet
> reclaimed)". Do you think that shortening conntrack timeout policy will help?
> Or, should we make it larger so there will be fewer conntrack table update and
> flush attempts?
>
Lazuardi Nasution writes:
> Hi Paolo,
>
> Would you mind to explain this to me? Currently, I'm still looking for
> compiling options of installed OVS-DPDK from Ubuntu repo. After that, I'll try
> your patch and compile it with same options.
>
the idea is to avoid to include two keys with the
Hello,
thanks for reporting this.
I had a look at it, and, although this needs to be confirmed, I suspect
it's related to nat (CT_CONN_TYPE_UN_NAT) and expired connections (but
not yet reclaimed).
The nat part does not necessarily perform any actual translation, but
could still be triggered by
