Hi Balaji,
Thanks for replying. Yes, I have that wiki and followed that, may be it is out
dated. I have mentioned that in a different thread on yesterday (attached here).
I have tried to build from different release versions, initially with v18.10 as
mentioned in the wiki. Currently, I am v20.
[Sorry hit the ‘send’ by mistake..]
Did you try that solution?
Thanks!
--
Regards,
Balaji.
From: "Balaji Venkatraman (balajiv)"
Date: Wednesday, February 26, 2020 at 4:46 PM
To: "Majumdar, Kausik" , vpp-dev
Cc: "vppsb-...@lists.fd.io"
Subject: Re: [vpp-dev] VPP with FRR Bring-up - Netlink a
Hi Kausik,
I see a project that incorporated FRR with VPP.
x https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP
--
Regards,
Balaji.
From: on behalf of "Majumdar, Kausik"
Date: Wednesday, February 26, 2020 at 4:31 PM
To: vpp-dev
Cc: "vppsb-...@lists.fd.io" , "Majumdar,
Hi folks,
I wanted to start a new thread on the discussion related to VPP with FRR bring
up and get this working together for VPP as a Data plane with FRR as a Control
/Routing plane. Please chime in if you have already got VPP and FRR working
together or can help on the current issues.
I am
Hi Nick,
I agree the current bypass node for various tunnel types, including geneve,
gtpu, vxlan, and vxlan_gbp all have this issue in its hash lookup using only
incoming packet DIP without checking VRF. It is generally not an issue if
bypass feature is enabled on all interfaces which are on t
[Edited Message Follows]
Route Injection VPP IPSec: " Routing traffic through ipsec0 interface on the
VPP responder "
*Setup Details:* StrongSwan IPsec client initiator which establishes 250 IPSec
tunnels with the VPP head-end responder.
*Case # Only one IPSec tunnel:*
ipip0 (ipsec00) interfac
[Edited Message Follows]
Folks,
I am seeing packet congestion drop errors "esp4-encrypt-tun-handoff". What
could be the reason for this and how can i debug this further?
124 ikev2 IKEv2 packets processed
31 ikev2 IKE_SA_INIT retr
Hi Florin,
Thanks for the clarification.
Thanks,
-Raj
On Wed, Feb 26, 2020 at 5:14 PM Florin Coras wrote:
> Hi Raj,
>
> Now that’s interesting. VPP detects when an application dies (binary api
> mechanism) and forces through the session layer a de-attach which in turn
> leads to an unbind.
>
>
Right... I added a command-line option to set the default interface MTU. Unless
someone uses it, nothing changes...
See https://gerrit.fd.io/r/c/vpp/+/25473
Dave
-Original Message-
From: Christian Hopps
Sent: Wednesday, February 26, 2020 2:12 PM
To: Dave Barach (dbarach)
Cc: Christi
Hi Raj,
Now that’s interesting. VPP detects when an application dies (binary api
mechanism) and forces through the session layer a de-attach which in turn leads
to an unbind.
In case of udp, not tcp, we have a shim layer that redirects udp packets to
whomever registered for a certain port. I
Hi Dom,
It could be that you’re hitting more often the issues that I also encountered
locally. And yes, I noticed that even the server side has sporadic issues.
Given that iperf works fine with tcp, I assume tls re-segments data in a way
that iperf does not like.
Now, with respect to the thr
Hi,
When 2 or more UDP rx applications ( using VCL) receiving on the same port (
bind on the same port but different ip address) then on stopping either one of
the application , all other application stopped receiving the traffic. As soon
as , I restart the application all other applications als
Folks,
I am seeing packet congestion drop errors "esp4-encrypt-tun-handoff". What
could be the reason for this and how can i debug this further?
124 ikev2 IKEv2 packets processed
31 ikev2 IKE_SA_INIT retransmit
31 ip4-
Hi Florin,
Thanks once again! I was in the middle of collecting a bunch of information to
respond (basically nothing interesting in logs and the client does not crash,
it just sits there), and then on one miraculous run it actually worked. I was
hoping for a bit more performance (I only got 2.8
Route Injection VPP IPSec: " Routing traffic through ipsec0 interface on the
VPP responder "
*Setup Details:* StrongSwan IPsec client initiator which establishes 250 IPSec
tunnels with the VPP head-end responder.
*Case # Only one IPSec tunnel:*
ipip0 (ipsec00) interface and its straight forward
Hi Chuan,
Thanks for your interest. So far I have found it is not straight forward way to
build and bring up VPP with the plugins and that is required for FRR to work
with VPP.
Let me start a new thread to resolve the current issues with netlink and router
plugins compilation errors, I see th
FWIW, I actually like the 9k default as I suspect it means that the code path
for jumbo frames gets tested a lot more than is normal. If 1500 is the default
I suspect jumbo frame bugs will begin to creep in and go unnoticed.
It was nice not having to fix any 9k bugs when we started using VPP. :)
+1
On 2/26/2020 10:50 AM, Andrew Yourtchenko wrote:
+1, good idea to remove naginator imho.
--a
On 26 Feb 2020, at 16:29, Ed Kern via Lists.Fd.Io
wrote:
adding vpp-dev to to:
A bad retry vote on a job (jan will be sending it along) caused a merge to
happen with this bug.
vpp folks….
S
Hi Dom,
Is the iperf client returning an error or does it crash? Do you get any errors
in /var/log/syslog?
Also, do a “sh session verbose” on both nodes to see if there’s any data
pending in the rx/tx fifos.
Regards,
Florin
> On Feb 26, 2020, at 10:26 AM, dchons via Lists.Fd.Io
> wrote:
Hi Florin,
Thanks so much for trying this out and for the suggestions. Unfortunately this
isn't working in my setup. Here's what I did just to make sure I'm not missing
anything.
I generated the key and cert as follows:
*openssl req -newkey rsa:2048 -nodes -keyout ldp.key -x509 -days 365 -out
Hi,
According to 3gpp 29.281, TEIDs used in a GTPU tunnel could be different in
"up" and "down" direction. At EMnify we depend on this feature.
We developed a patch but it changes API in incompatible ways, excerpt:
@@ -38,8 +39,9 @@ define gtpu_add_del_tunnel
vl_api_interface_index_t mcast_sw_i
Hi,
There are multiple kinds of bypass nodes in vpp. Bypass nodes intercept packets
matching certain criteria and pass them directly to the protocol handler node.
I am going to use GTPU as the illustrating example.
Bypass node SHOULD intercept packets with destination IP matching a local
addre
Hmm so that’s an interesting question. Adding a new API into an existing file
will still change the CRC on the plugin/module - which means that if we are
aiming for binary compatibility (which is I think what we are doing) - it means
we can only allow the one-shot addition of new .api files, rig
Hi Kausik,
The remaining build errors are from the router plugin, those I cannot help with.
/neale
On 26/02/2020 08:19, "vpp-dev@lists.fd.io on behalf of Majumdar, Kausik"
wrote:
Hi Neale,
Thanks for your reply! Yes, now I have compiled vpp v20.01 codebase, built
rpm pac
Hi Dom,
Out of curiosity, I tried out testing tls throughput with iperf. Note that this
is a bit of a hack, i.e., ldp can transparently convert tcp connections into
tls connections if the right environment variables are set (see more [1]).
Sporadically, this does exhibit some setup instability
> How long do we have to wait?
> I'd much rather revert 22698.
Go ahead, it looks it will take a day or two on our end.
Vratko.
-Original Message-
From: otr...@employees.org
Sent: Wednesday, February 26, 2020 5:19 PM
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco)
Cc: Dave
> as soon as the CRC of any existing messages does not change, a patch is okay
> to include into 19.08
Does that mean we want an api-crc job also for 1908 stream?
We currently have api-crc job only for master,
because other branches were not expected to edit .api files.
Vratko.
From: vpp-dev@li
> On 26 Feb 2020, at 16:36, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at
> Cisco) via Lists.Fd.Io wrote:
>
> This [0] change got merged. It got wrong Verified+1
> due to naginator retrying one job
> (and Gerrit forgetting about other ones).
> Basically the same as these [1] two [2] olde
Thanks Dave, that would be good. -John
From: Dave Barach (dbarach)
Sent: Wednesday, February 26, 2020 10:08 AM
To: John Lo (loj) ; vpp-dev
Subject: RE: Change interface default MTU to 1500
OK, how about this: I'll add a VLIB_CONFIG_FUNCTION, or [more likely] add a
system default MTU parameter
+1, good idea to remove naginator imho.
--a
> On 26 Feb 2020, at 16:29, Ed Kern via Lists.Fd.Io
> wrote:
>
> adding vpp-dev to to:
>
> A bad retry vote on a job (jan will be sending it along) caused a merge to
> happen with this bug.
>
> vpp folks….
>
> Since we have gone a few months now
I am also interested in frr integration with vpp. Could you please share
detailed steps once you figure it out?
On Tue, Feb 25, 2020, 11:34 PM Ray Kinsella wrote:
>
>
> I am not sure how accurate / current the information from the wiki is.
>
> However looks like you are missing the Intel Multi-b
This [0] change got merged. It got wrong Verified+1
due to naginator retrying one job
(and Gerrit forgetting about other ones).
Basically the same as these [1] two [2] older failures.
Not sure whether is better to revert the change
or wait for CSIT to catch up.
Vratko.
[0] https://gerrit.fd.io/r
adding vpp-dev to to:
A bad retry vote on a job (jan will be sending it along) caused a merge to
happen with this bug.
vpp folks….
Since we have gone a few months now with no jenkins connection issues (one of
the main drivers for the retry introduction). Id like
to propose removing the retry f
From: vpp-dev@lists.fd.io On Behalf Of Dave Barach via
Lists.Fd.Io
Sent: Wednesday, February 26, 2020 4:10 PM
To: Maciek Konstantynowicz (mkonstan)
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...
Thanks... Dave
From: Maciek Konstantyno
Thanks... Dave
From: Maciek Konstantynowicz (mkonstan)
Sent: Wednesday, February 26, 2020 10:09 AM
To: Dave Barach (dbarach)
Cc: csit-...@lists.fd.io; Ed Kern (ejk) ; Dave Wallace
(dwallace) ; vpp-dev
Subject: Re: Gerrit 25463 fails API CRC check for no obvious reason...
Hi Dave, thanks for n
Hi Dave, thanks for notifying, we have just discussed this on the CSIT project
call, Vratko is looking into this.
Here are the incompatible API CRCs that are tripping the job. Will notify on
this thread once issue is nailed down.
Cheers,
-Maciek
13:24:04 Incompatible API CRCs found in .api.jso
I merged a bunch of .api changes from Jakub today. Might be related...
Ole
> On 26 Feb 2020, at 15:44, Dave Barach via Lists.Fd.Io
> wrote:
>
> Other patches failing as well. Please investigate AYEC.
>
> Thanks... Dave
>
> P.S. See https://gerrit.fd.io/r/c/vpp/+/25463. No .api files involved.
OK, how about this: I'll add a VLIB_CONFIG_FUNCTION, or [more likely] add a
system default MTU parameter to one of the existing config functions.
I'm sick of cluttering configs with interface MTU commands...
Thanks... Dave
From: John Lo (loj)
Sent: Wednesday, February 26, 2020 9:47 AM
To: Dave
Certainly in VPP 17.01 jumbo frames were not handled properly by VPP and in our
application we had to reset the MTU in VPP to be 1500 via something like:
set interface mtu 1500 device_37/0/0
Greg
From: vpp-dev@lists.fd.io On Behalf Of John Lo (loj) via
Lists.Fd.Io
Sent: 26 February 2020 14:47
Hi Dave,
My memory was that in data center or cloud environment it is desirable to set
MTU to jumbo frame size to avoid fragmentation by default. Thus the question
would be if it is reasonable to set default MTU size to 9000 for VPP and what
kind of problem is it causing that would be fixed by
Other patches failing as well. Please investigate AYEC.
Thanks... Dave
P.S. See https://gerrit.fd.io/r/c/vpp/+/25463. No .api files involved.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15541): https://lists.fd.io/g/vpp-dev/message/15541
Mute T
Coverity run failed today.
Current number of outstanding issues are 7
Newly detected: 0
Eliminated: 1
More details can be found at
https://scan.coverity.com/projects/fd-io-vpp/view_defects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15540): ht
Folks,
I'm considering changing the default interface MTU to 1500, from the current
value of 9000:
ethernet_register_interface (...)
{
/* Standard default ethernet MTU. */
vnet_sw_interface_set_mtu (vnm, hi->sw_if_index, 9000);
}
I've pinged some folks, and nobody rememb
43 matches
Mail list logo
