Hi,
Could you try this out [1]? I’ve hit this issue myself today but with udp
sessions. Unfortunately, as you’ve correctly pointed out, we were forcing a
cleanup only on the non-fixed local port branch.
Regards,
Florin
[1] https://gerrit.fd.io/r/c/vpp/+/38473
> On Mar 13, 2023, at 7:35
Hi list,
We have update coded from the upstream session changes to our code base
and find a possible bug which cause tcp connection can't be established
anymore.
Our scenario is that we will connect to a remote tcp server with specified
local port and local ip, however, new vpp code have
Production upgrade complete. If you have any issues, please open a
ticket at support.linuxfoundation.org.
Thank you,
Vanessa
On 3/13/23 13:00, Vanessa Valderrama wrote:
Sandbox upgrade complete
Starting on production now
On 3/13/23 12:30, Vanessa Valderrama wrote:
*What*:
The Linux
Thank you for bringing this to the fore.
I am noticing something interesting along the same lines as well during my
investigation.
I am using strongswan as the initiator and VPP Ikev2 as the responder.
My observations are:
1. Strongswan initiator forceencap=yes and VPP responder ikev2 profile
Sandbox upgrade complete
Starting on production now
On 3/13/23 12:30, Vanessa Valderrama wrote:
*What*:
The Linux Foundation been made aware of a security issue with the
Jenkins systems that needs immediate resolution
*When*:
We're starting the sandbox upgrade now
Putting production in
*What*:
The Linux Foundation been made aware of a security issue with the
Jenkins systems that needs immediate resolution
*When*:
We're starting the sandbox upgrade now
Putting production in shutdown mode. The upgrade will be done at 18:00.
(all running jobs will be aborted at this time)
Hi Team,
All UDP packet being dropped at “ipsec4_input_node” if ipsec inbound and
outbound policy configured. Not that udp_encp is not enabled.
Where TCP and ICMP has no such issue.
System is treating normal UDP and UDP encapsulated ESP packet in same way.
Probably we have to use DST and SRC
