Re: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build failures

[Majumdar, Kausik]

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.01. These plugins doesn’t build 
properly.

Few issues –


  1.  I didn’t find ‘bootstrap.sh’ file under build-root dir as mentioned in 
the wiki.

2.   $ cd build-root/

3.   $ ./bootstrap.sh

2. The VPP vnet/ip dir doesn’t contain ip6_neighbor.h, but it is included in 
tap_inject_netlink.c

/root/vpp/src/vnet/ip
[root@localhost ip]# ls ip6*
ip6_error.hip6_forward.h ip6_hop_by_hop.h ip6_input.h  
ip6_ll_table.c  ip6_ll_types.h  ip6_punt_drop.c
ip6_format.c   ip6.h ip6_hop_by_hop_packet.h  ip6_link.c   
ip6_ll_table.h  ip6_packet.hip6_to_ip4.h
ip6_forward.c  ip6_hop_by_hop.c  ip6_input.c  ip6_link.h   
ip6_ll_types.c  ip6_pg.c

/root/vpp/build-data/../router/router/tap_inject_netlink.c:19:34: fatal error: 
vnet/ip/ip6_neighbor.h: No such file or directory
 #include 



  1.  The netlink build issue was discussed in the thread, but not sure what 
was the resolution of it.
https://lists.fd.io/g/vpp-dev/topic/vppsb_netlink_build_failing/27825040?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,27825040


Thanks,
Kausik

From: Balaji Venkatraman (balajiv) 
Sent: Wednesday, February 26, 2020 4:48 PM
To: Majumdar, Kausik ; vpp-dev 

Cc: vppsb-...@lists.fd.io
Subject: Re: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build 
failures

Message received from external source. Exercise caution when opening 
attachments, clicking links, or exchanging information.

[Sorry hit the ‘send’ by mistake..]

Did you try that solution?

Thanks!
--
Regards,
Balaji.


From: "Balaji Venkatraman (balajiv)" 
mailto:bala...@cisco.com>>
Date: Wednesday, February 26, 2020 at 4:46 PM
To: "Majumdar, Kausik" 
mailto:kausik.majum...@commscope.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Cc: "vppsb-...@lists.fd.io" 
mailto:vppsb-...@lists.fd.io>>
Subject: Re: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build 
failures

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: mailto:vpp-dev@lists.fd.io>> on behalf of "Majumdar, 
Kausik" mailto:kausik.majum...@commscope.com>>
Date: Wednesday, February 26, 2020 at 4:31 PM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: "vppsb-...@lists.fd.io" 
mailto:vppsb-...@lists.fd.io>>, "Majumdar, Kausik" 
mailto:kausik.majum...@commscope.com>>
Subject: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build 
failures


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 currently facing issues to build VPP plugins for netlink and router.


  1.  Netlink build error -

I looked into the previous discussion on netlink compilation issues, I didn’t 
find proper resolution for it. I made simple hack in the codebase and with that 
I was able to build netlink lib. I am sure folks have gone through this issue, 
so would like to know if any fix or patch is available.

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install

 Building netlink in /root/vpp/build-root/build-vpp_debug-native/netlink 

make[1]: Entering directory 
`/root/vpp/build-root/build-vpp_debug-native/netlink'
  CC   librtnl/netns.lo
  CC   librtnl/rtnl.lo
/root/vpp/build-data/../netlink/librtnl/rtnl.c: In function 'rtnl_socket_open':
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: error: 
'RTNLGRP_MPLS_ROUTE' undeclared (first use in this function)
 grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
   ^
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: note: each undeclared 
identifier is reported only once for each function it appears in
make[1]: *** [librtnl/rtnl.lo] Error 1
make[1]: *** Waiting for unfinished jobs
/root/vpp/build-data/../netlink/librtnl/netns.c:69:5: error: 'RTA_VIA' 
undeclared here (not in a function)
   _(RTA_VIA, via, 1)\
 ^
/root/vpp

Re: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build failures

[Balaji Venkatraman via Lists.Fd.Io]

[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 and Router Plugin build 
failures

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, Kausik" 

Subject: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build 
failures


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 currently facing issues to build VPP plugins for netlink and router.


  1.  Netlink build error -

I looked into the previous discussion on netlink compilation issues, I didn’t 
find proper resolution for it. I made simple hack in the codebase and with that 
I was able to build netlink lib. I am sure folks have gone through this issue, 
so would like to know if any fix or patch is available.

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install

 Building netlink in /root/vpp/build-root/build-vpp_debug-native/netlink 

make[1]: Entering directory 
`/root/vpp/build-root/build-vpp_debug-native/netlink'
  CC   librtnl/netns.lo
  CC   librtnl/rtnl.lo
/root/vpp/build-data/../netlink/librtnl/rtnl.c: In function 'rtnl_socket_open':
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: error: 
'RTNLGRP_MPLS_ROUTE' undeclared (first use in this function)
 grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
   ^
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: note: each undeclared 
identifier is reported only once for each function it appears in
make[1]: *** [librtnl/rtnl.lo] Error 1
make[1]: *** Waiting for unfinished jobs
/root/vpp/build-data/../netlink/librtnl/netns.c:69:5: error: 'RTA_VIA' 
undeclared here (not in a function)
   _(RTA_VIA, via, 1)\
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:82:13: note: in definition of 
macro '_'
 .type = t, .unique = u, \
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:86:3: note: in expansion of 
macro 'ns_foreach_rta'
   ns_foreach_rta
   ^
make[1]: *** [librtnl/netns.lo] Error 1
make[1]: Leaving directory `/root/vpp/build-root/build-vpp_debug-native/netlink'
make: *** [netlink-build] Error 2

I have applied the following diff change in my local codebase and netlink 
compiled fine.

diff --git a/netlink/librtnl/netns.c b/netlink/librtnl/netns.c
index 1b40227..8ecf02b 100644
--- a/netlink/librtnl/netns.c
+++ b/netlink/librtnl/netns.c
@@ -66,7 +66,6 @@ u8 *format_ns_link (u8 *s, va_list *args)
 #define ns_foreach_rta  \
   _(RTA_DST, dst, 1)\
   _(RTA_SRC, src, 1)\
-  _(RTA_VIA, via, 1)\
   _(RTA_GATEWAY, gateway, 1)\
   _(RTA_IIF, iif, 1)\
   _(RTA_OIF, oif, 1)\
diff --git a/netlink/librtnl/rtnl.c b/netlink/librtnl/rtnl.c
index a849dc6..9879e14 100644
--- a/netlink/librtnl/rtnl.c
+++ b/netlink/librtnl/rtnl.c
@@ -266,7 +266,7 @@ static int rtnl_socket_open(rtnl_ns_t *ns)
 .nl_groups = grpmask(RTNLGRP_LINK)| grpmask(RTNLGRP_IPV6_IFADDR) |
 grpmask(RTNLGRP_IPV4_IFADDR) | grpmask(RTNLGRP_IPV4_ROUTE) |
 grpmask(RTNLGRP_IPV6_ROUTE) | grpmask(RTNLGRP_NEIGH) |
-grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
+grpmask(RTNLGRP_NOTIFY),
   };

   if (bind(ns->rtnl_socket, (struct sockaddr*) &addr, sizeof(addr))) {


[root@localhost vpp]# ls 
/root/vpp/build-root/install-vpp_debug-native/netlink/lib64
librtnl.a   librtnl.solibrtnl.so.0.0.0   testrtnl_plugin.la  
testrtnl_plugin.so.0
librtnl.la  librtnl.so.0  testrtnl_plugin.a  testrtnl_plugin.so  
testrtnl_plugin.so.0.0.0



  1.  router build error –

Is there any fix available for the tap_inject_netlink.c failure?

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install
 Arch for platform 'vpp' is native 

 Building router in /root/vpp/build-root/build-vpp_debug-native/router 
make[1]: Entering directory `/root/vpp/build-root/build-vpp_debug-native/router'
  CC   router/tap_inject_netlink.lo
  CC   router/tap_inject_node.lo
/root/vpp/build-data/../router/router/tap_inject_netlink.c:19:34: fatal error: 
vnet/ip/ip6_neighbor.h: No such file or directory
 #include 

Re: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build failures

[Balaji Venkatraman via Lists.Fd.Io]

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, Kausik" 

Subject: [vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build 
failures


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 currently facing issues to build VPP plugins for netlink and router.


  1.  Netlink build error -

I looked into the previous discussion on netlink compilation issues, I didn’t 
find proper resolution for it. I made simple hack in the codebase and with that 
I was able to build netlink lib. I am sure folks have gone through this issue, 
so would like to know if any fix or patch is available.

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install

 Building netlink in /root/vpp/build-root/build-vpp_debug-native/netlink 

make[1]: Entering directory 
`/root/vpp/build-root/build-vpp_debug-native/netlink'
  CC   librtnl/netns.lo
  CC   librtnl/rtnl.lo
/root/vpp/build-data/../netlink/librtnl/rtnl.c: In function 'rtnl_socket_open':
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: error: 
'RTNLGRP_MPLS_ROUTE' undeclared (first use in this function)
 grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
   ^
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: note: each undeclared 
identifier is reported only once for each function it appears in
make[1]: *** [librtnl/rtnl.lo] Error 1
make[1]: *** Waiting for unfinished jobs
/root/vpp/build-data/../netlink/librtnl/netns.c:69:5: error: 'RTA_VIA' 
undeclared here (not in a function)
   _(RTA_VIA, via, 1)\
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:82:13: note: in definition of 
macro '_'
 .type = t, .unique = u, \
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:86:3: note: in expansion of 
macro 'ns_foreach_rta'
   ns_foreach_rta
   ^
make[1]: *** [librtnl/netns.lo] Error 1
make[1]: Leaving directory `/root/vpp/build-root/build-vpp_debug-native/netlink'
make: *** [netlink-build] Error 2

I have applied the following diff change in my local codebase and netlink 
compiled fine.

diff --git a/netlink/librtnl/netns.c b/netlink/librtnl/netns.c
index 1b40227..8ecf02b 100644
--- a/netlink/librtnl/netns.c
+++ b/netlink/librtnl/netns.c
@@ -66,7 +66,6 @@ u8 *format_ns_link (u8 *s, va_list *args)
 #define ns_foreach_rta  \
   _(RTA_DST, dst, 1)\
   _(RTA_SRC, src, 1)\
-  _(RTA_VIA, via, 1)\
   _(RTA_GATEWAY, gateway, 1)\
   _(RTA_IIF, iif, 1)\
   _(RTA_OIF, oif, 1)\
diff --git a/netlink/librtnl/rtnl.c b/netlink/librtnl/rtnl.c
index a849dc6..9879e14 100644
--- a/netlink/librtnl/rtnl.c
+++ b/netlink/librtnl/rtnl.c
@@ -266,7 +266,7 @@ static int rtnl_socket_open(rtnl_ns_t *ns)
 .nl_groups = grpmask(RTNLGRP_LINK)| grpmask(RTNLGRP_IPV6_IFADDR) |
 grpmask(RTNLGRP_IPV4_IFADDR) | grpmask(RTNLGRP_IPV4_ROUTE) |
 grpmask(RTNLGRP_IPV6_ROUTE) | grpmask(RTNLGRP_NEIGH) |
-grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
+grpmask(RTNLGRP_NOTIFY),
   };

   if (bind(ns->rtnl_socket, (struct sockaddr*) &addr, sizeof(addr))) {


[root@localhost vpp]# ls 
/root/vpp/build-root/install-vpp_debug-native/netlink/lib64
librtnl.a   librtnl.solibrtnl.so.0.0.0   testrtnl_plugin.la  
testrtnl_plugin.so.0
librtnl.la  librtnl.so.0  testrtnl_plugin.a  testrtnl_plugin.so  
testrtnl_plugin.so.0.0.0



  1.  router build error –

Is there any fix available for the tap_inject_netlink.c failure?

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install
 Arch for platform 'vpp' is native 

 Building router in /root/vpp/build-root/build-vpp_debug-native/router 
make[1]: Entering directory `/root/vpp/build-root/build-vpp_debug-native/router'
  CC   router/tap_inject_netlink.lo
  CC   router/tap_inject_node.lo
/root/vpp/build-data/../router/router/tap_inject_netlink.c:19:34: fatal error: 
vnet/ip/ip6_neighbor.h: No such file or directory
 #include 
  ^
compilation terminated.
/root/vpp/build-data/../router/router/tap_inject_node.c: In function 'tap_rx':
/root/vpp/build-data/../router/router/tap_inject_node.c:182:29: error: 
'VLIB_BUFFER_DATA_SIZE' undeclared (first use in this function)
 #define MTU_BUFFERS ((MTU + VLIB_BUFFER_DATA_SIZE - 1) /

[vpp-dev] VPP with FRR Bring-up - Netlink and Router Plugin build failures

[Majumdar, Kausik]

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 currently facing issues to build VPP plugins for netlink and router.


  1.  Netlink build error -

I looked into the previous discussion on netlink compilation issues, I didn't 
find proper resolution for it. I made simple hack in the codebase and with that 
I was able to build netlink lib. I am sure folks have gone through this issue, 
so would like to know if any fix or patch is available.

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install

 Building netlink in /root/vpp/build-root/build-vpp_debug-native/netlink 

make[1]: Entering directory 
`/root/vpp/build-root/build-vpp_debug-native/netlink'
  CC   librtnl/netns.lo
  CC   librtnl/rtnl.lo
/root/vpp/build-data/../netlink/librtnl/rtnl.c: In function 'rtnl_socket_open':
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: error: 
'RTNLGRP_MPLS_ROUTE' undeclared (first use in this function)
 grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
   ^
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: note: each undeclared 
identifier is reported only once for each function it appears in
make[1]: *** [librtnl/rtnl.lo] Error 1
make[1]: *** Waiting for unfinished jobs
/root/vpp/build-data/../netlink/librtnl/netns.c:69:5: error: 'RTA_VIA' 
undeclared here (not in a function)
   _(RTA_VIA, via, 1)\
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:82:13: note: in definition of 
macro '_'
 .type = t, .unique = u, \
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:86:3: note: in expansion of 
macro 'ns_foreach_rta'
   ns_foreach_rta
   ^
make[1]: *** [librtnl/netns.lo] Error 1
make[1]: Leaving directory `/root/vpp/build-root/build-vpp_debug-native/netlink'
make: *** [netlink-build] Error 2

I have applied the following diff change in my local codebase and netlink 
compiled fine.

diff --git a/netlink/librtnl/netns.c b/netlink/librtnl/netns.c
index 1b40227..8ecf02b 100644
--- a/netlink/librtnl/netns.c
+++ b/netlink/librtnl/netns.c
@@ -66,7 +66,6 @@ u8 *format_ns_link (u8 *s, va_list *args)
 #define ns_foreach_rta  \
   _(RTA_DST, dst, 1)\
   _(RTA_SRC, src, 1)\
-  _(RTA_VIA, via, 1)\
   _(RTA_GATEWAY, gateway, 1)\
   _(RTA_IIF, iif, 1)\
   _(RTA_OIF, oif, 1)\
diff --git a/netlink/librtnl/rtnl.c b/netlink/librtnl/rtnl.c
index a849dc6..9879e14 100644
--- a/netlink/librtnl/rtnl.c
+++ b/netlink/librtnl/rtnl.c
@@ -266,7 +266,7 @@ static int rtnl_socket_open(rtnl_ns_t *ns)
 .nl_groups = grpmask(RTNLGRP_LINK)| grpmask(RTNLGRP_IPV6_IFADDR) |
 grpmask(RTNLGRP_IPV4_IFADDR) | grpmask(RTNLGRP_IPV4_ROUTE) |
 grpmask(RTNLGRP_IPV6_ROUTE) | grpmask(RTNLGRP_NEIGH) |
-grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
+grpmask(RTNLGRP_NOTIFY),
   };

   if (bind(ns->rtnl_socket, (struct sockaddr*) &addr, sizeof(addr))) {


[root@localhost vpp]# ls 
/root/vpp/build-root/install-vpp_debug-native/netlink/lib64
librtnl.a   librtnl.solibrtnl.so.0.0.0   testrtnl_plugin.la  
testrtnl_plugin.so.0
librtnl.la  librtnl.so.0  testrtnl_plugin.a  testrtnl_plugin.so  
testrtnl_plugin.so.0.0.0



  1.  router build error -

Is there any fix available for the tap_inject_netlink.c failure?

[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install
 Arch for platform 'vpp' is native 

 Building router in /root/vpp/build-root/build-vpp_debug-native/router 
make[1]: Entering directory `/root/vpp/build-root/build-vpp_debug-native/router'
  CC   router/tap_inject_netlink.lo
  CC   router/tap_inject_node.lo
/root/vpp/build-data/../router/router/tap_inject_netlink.c:19:34: fatal error: 
vnet/ip/ip6_neighbor.h: No such file or directory
 #include 
  ^
compilation terminated.
/root/vpp/build-data/../router/router/tap_inject_node.c: In function 'tap_rx':
/root/vpp/build-data/../router/router/tap_inject_node.c:182:29: error: 
'VLIB_BUFFER_DATA_SIZE' undeclared (first use in this function)
 #define MTU_BUFFERS ((MTU + VLIB_BUFFER_DATA_SIZE - 1) / VLIB_BUFFER_DATA_SIZE)
 ^
/root/vpp/build-data/../router/router/tap_inject_node.c:190:20: note: in 
expansion of macro 'MTU_BUFFERS'
   struct iovec iov[MTU_BUFFERS];
^
/root/vpp/build-data/../router/router/tap_inject_node.c:182:29: note: each 
undeclared identifier is reported only once for each function it appears in
 #define MTU_BUFFERS ((MTU

Re: [vpp-dev] VRF-aware bypass nodes

[John Lo (loj) via Lists.Fd.Io]

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 the same VRF/IP-table 
corresponding to the same underlay network.  If another underlay VRF is setup 
on other interfaces with bypass enabled, the bypass error as you described will 
happen.

I have no objection if you like to submit a patch to fix this limitation.  I 
hope you are willing to fix bypass node not just for gtpu but all 4 tunnel 
types.  The code for all 4 bypass nodes are very similar except  tunnel type 
check, validation, and node names, etc.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Nick Zavaritsky
Sent: Wednesday, February 26, 2020 12:23 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VRF-aware bypass nodes

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 
address and UDP destination port equal to 2152.

Bypass node MUST NOT intercept a packet if destination IP doesn’t match a local 
address. Otherwise enabling GTPU bypass would change the observable system 
behaviour.

An address is local within a certain VRF. It’s possible that an address is 
local in one VRF but it’s not in another. But GTPU bypass node is not VRF aware.

Image a vpp setup with 2 interfaces, associated with different VRF-s. The first 
interface address is 10.0.10.100, the other one — 192.168.0.7. Both have GTPU 
bypass enabled. Now GTPU bypass in the second interface will intercept packets 
sent to 10.0.10.100 (the first interface’s address), though it shouldn’t.

This is a somewhat contrived example, but it looks like bypass node should be 
VRF-aware for correctness.

Am I missing something?

Would you be open to a patch making GTPU bypass VRF-aware?

Best,
Nick
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15575): https://lists.fd.io/g/vpp-dev/message/15575
Mute This Topic: https://lists.fd.io/mt/71569502/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP IPSec Responder Server (VPN Server) VPP Route injection

[ravinder . yadav]

[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) interface and its straight forward to add a route for remote ip 
range.

*Case # When you have more than two IPSec, the ipsec interface name depends on 
which tunnel gets established first.*
ipip0 interface (Can't add route because don't know which remote ip range): 
Could be remote 1 or 2
ipip1 interface (Can't add route because don't know which remote ip range): 
Could be remote 1 or 2

This becomes a big issue when you have 250 clients coming in at the same time. 
It become impossible to decide which route gets injected on which interface!!

-Ravin

Ref: 
https://wiki.fd.io/view/VPP/IPSec_and_IKEv2#Routing_traffic_through_ipsec0_interface_on_the_VPP_responder

Routing traffic through ipsec0 interface on the VPP responder

At this point of the configuration, you still do not have end to end secure 
connectivity. You need to route traffic through ipsec0 created interface on 
VPP. There are two ways of doing it.

First: using a dummy IP address.

set interface state ipsec0 up
set interface ip address ipsec0 11.11.11.11/32
ip route add 192.168.3.0/24 via 11.11.11.11 ipsec0

Second: binding logical and physical interfaces

You must use tunnel endpoint interface.

ip route add 192.168.3.0/24 via ipsec0
set interface state ipsec0 up
set interface unnumbered ipsec0 use TenGigabitEthernet4/0/0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15567): https://lists.fd.io/g/vpp-dev/message/15567
Mute This Topic: https://lists.fd.io/mt/71571955/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Error: esp4-encrypt-tun-handoff : congestion drop #ipsec

[ravinder . yadav]

[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 retransmit
31             ip4-udp-lookup             no error
19061984            esp4-decrypt-tun            ESP pkts received
1            esp4-decrypt-tun            Integrity check failed
134757254            esp4-encrypt-tun            ESP pkts received
19061984            ipsec4-tun-input            good packets received
*33913        esp4-encrypt-tun-handoff        congestion drop*
31                ip4-glean               ARP requests sent
263             ethernet-input             no error

Thank you,
-Ravin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15569): https://lists.fd.io/g/vpp-dev/message/15569
Mute This Topic: https://lists.fd.io/mt/71573632/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Multiple UDP receiver applications on same port #vpp-hoststack

[Raj Kumar]

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.
>
> In case of udp, not tcp, we have a shim layer that redirects udp packets
> to whomever registered for a certain port. In your case, udp-input was
> registered twice but because currently we don’t have a reference count, the
> unbind removes the registration for both binds.
>
> Will add it to my todo list if nobody beats me to it.
>
> Regards,
> Florin
>
> On Feb 26, 2020, at 1:28 PM, Raj Kumar  wrote:
>
> 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 also
> start receiving the traffic.
>
> vpp# sh ip6 int
>
> vppnet1.2001 is admin up
>
>   Local unicast address(es):
>
> fd0d:edc4::2001::213/64
>
> fd0d:edc4::2001::223/64
>
>   Link-local address(es):
>
> fe80::ba83:3ff:fe79:af8c
> When both applications are running : -
> vpp# sh session verbose 1
> ConnectionState  Rx-f
> Tx-f
> [#0][U] fd0d:edc4::2001::213:9915->:::0   -  0
>  0
> [#0][U] fd0d:edc4::2001::223:9915->:::0   -  0
>  0
> Thread 0: active sessions 2
> Thread 1: no sessions
> Thread 2: no sessions
> Thread 3: no sessions
> Thread 4: no sessions
>
> ConnectionState  Rx-f
> Tx-f
> [#5][U] fd0d:edc4::2001::213:9915->fd0d:edc4:f-  15226
>  0
> Thread 5: active sessions 1
>
> ConnectionState  Rx-f
> Tx-f
> [#6][U] fd0d:edc4::2001::223:9915->fd0d:edc4:f-  0
>  0
> Thread 6: active sessions 1
>
>
> On stopping first application  : -
>
> vpp# sh session verbose 1
>
> ConnectionState  Rx-f
> Tx-f
>
> [#0][U] fd0d:edc4::2001::223:9915->:::0   -  0
>  0
>
> Thread 0: active sessions 1
>
> Thread 1: no sessions
>
> Thread 2: no sessions
>
> Thread 3: no sessions
>
> Thread 4: no sessions
>
> Thread 5: no sessions
>
>
> ConnectionState  Rx-f
> Tx-f
>
> [#6][U] fd0d:edc4::2001::223:9915->fd0d:edc4:f-  0
>  0
>
>
> Thread 6: active sessions 1
> One active session is there but in 'sh err'  "no listener punt" error
> increments and application is not receiving the data.
>
> 310150540 ip6-udp-lookup no listener punt
>
> packet trace :-
>
> --- Start of thread 6 vpp_wk_5 ---
> Packet 1
>
> 01:12:04:676114: dpdk-input
>   vppnet1 rx queue 2
>   buffer 0x10b18f: current data 0, length 7634, buffer-pool 0, ref-count
> 1, totlen-nifb 0, trace handle 0x600
>ext-hdr-valid
>   PKT MBUF: port 0, nb_segs 1, pkt_len 7634
> buf_len 9344, data_len 7634, ol_flags 0x182, data_off 128, phys_addr
> 0x744c6440
> packet_type 0x2e1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x678c0829 fdir.hi 0x0 fdir.lo 0x678c0829
> Packet Offload Flags
>   PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
>   PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>   PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   RTE_PTYPE_L3_IPV6_EXT_UNKNOWN (0x00e0) IPv6 packet with or without
> extension headers
>   RTE_PTYPE_L4_UDP (0x0200) UDP packet
>   IP6: b8:83:03:79:9f:e8 -> b8:83:03:79:af:8c 802.1q vlan 2001
>   UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
> tos 0x00, flow label 0x0, hop limit 64, payload length 7576
>   UDP: 23456 -> 9915
> length 7576, checksum 0x225d
> 01:12:04:676154: ethernet-input
>   frame: flags 0x3, hw-if-index 2, sw-if-index 2
>   IP6: b8:83:03:79:9f:e8 -> b8:83:03:79:af:8c 802.1q vlan 2001
> 01:12:04:676156: ip6-input
>   UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
> tos 0x00, flow label 0x0, hop limit 64, payload length 7576
>   UDP: 23456 -> 9915
> length 7576, checksum 0x225d
> 01:12:04:676164: ip6-lookup
>   fib 0 dpo-idx 20 flow hash: 0x
>   UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
> tos 0x00, flow label 0x0, hop limit 64, payload length 7576
>   UDP: 23456 -> 9915
> length 7576, checksum 0x225d
> 01:12:04:676166: ip6-local
> UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
>   tos 0x00, flow label 0x0, hop limit 64, payload length 7576
> UDP: 23456 -> 9915
>   length 7576, checksum 0x225d
> 01:12:04:676169: ip6-udp-lookup
>   UDP: src-port 23456 

Re: [vpp-dev] Change interface default MTU to 1500

[Dave Barach via Lists.Fd.Io]

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: Christian Hopps ; John Lo (loj) ; 
vpp-dev 
Subject: Re: [vpp-dev] Change interface default MTU to 1500

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. :)

With that in mind, a local config default override seems better than a compiled 
default change.

Thanks,
Chris.

> On Feb 26, 2020, at 10:07 AM, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> 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 Barach (dbarach) ; vpp-dev 
> Subject: RE: Change interface default MTU to 1500
>  
> 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 changing it to 1500.
>  
> Regards,
> John
>  
> From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
> Lists.Fd.Io
> Sent: Wednesday, February 26, 2020 8:40 AM
> To: vpp-dev 
> Cc: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Change interface default MTU to 1500
>  
> 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 remembers why we’re setting the default 
> MTU to 9000.
>  
> Thanks... Dave 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15573): https://lists.fd.io/g/vpp-dev/message/15573
Mute This Topic: https://lists.fd.io/mt/71565329/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Multiple UDP receiver applications on same port #vpp-hoststack

[Florin Coras]

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. In your case, udp-input was registered 
twice but because currently we don’t have a reference count, the unbind removes 
the registration for both binds.

Will add it to my todo list if nobody beats me to it. 

Regards,
Florin

> On Feb 26, 2020, at 1:28 PM, Raj Kumar  wrote:
> 
> 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 also start 
> receiving the traffic.
> 
> 
> vpp# sh ip6 int
> 
> vppnet1.2001 is admin up
> 
>   Local unicast address(es):
> 
> fd0d:edc4::2001::213/64
> 
> fd0d:edc4::2001::223/64
> 
>   Link-local address(es):
> 
> fe80::ba83:3ff:fe79:af8c
> 
> When both applications are running : -
> vpp# sh session verbose 1
> ConnectionState  Rx-f  
> Tx-f
> [#0][U] fd0d:edc4::2001::213:9915->:::0   -  0 0
> [#0][U] fd0d:edc4::2001::223:9915->:::0   -  0 0
> Thread 0: active sessions 2
> Thread 1: no sessions
> Thread 2: no sessions
> Thread 3: no sessions
> Thread 4: no sessions
>
> ConnectionState  Rx-f  
> Tx-f
> [#5][U] fd0d:edc4::2001::213:9915->fd0d:edc4:f-  15226 0
> Thread 5: active sessions 1
>
> ConnectionState  Rx-f  
> Tx-f
> [#6][U] fd0d:edc4::2001::223:9915->fd0d:edc4:f-  0 0
> Thread 6: active sessions 1
>
> On stopping first application  : -
> 
> vpp# sh session verbose 1
> 
> ConnectionState  Rx-f  
> Tx-f
> 
> [#0][U] fd0d:edc4::2001::223:9915->:::0   -  0 0
> 
> Thread 0: active sessions 1
> 
> Thread 1: no sessions
> 
> Thread 2: no sessions
> 
> Thread 3: no sessions
> 
> Thread 4: no sessions
> 
> Thread 5: no sessions
> 
>
> ConnectionState  Rx-f  
> Tx-f
> 
> [#6][U] fd0d:edc4::2001::223:9915->fd0d:edc4:f-  0 0
> 
>
> Thread 6: active sessions 1
> 
> One active session is there but in 'sh err'  "no listener punt" error 
> increments and application is not receiving the data.
> 
> 310150540 ip6-udp-lookup no listener punt
> 
> packet trace :- 
> 
> --- Start of thread 6 vpp_wk_5 ---
> Packet 1
>
> 01:12:04:676114: dpdk-input
>   vppnet1 rx queue 2
>   buffer 0x10b18f: current data 0, length 7634, buffer-pool 0, ref-count 1, 
> totlen-nifb 0, trace handle 0x600
>ext-hdr-valid
>   PKT MBUF: port 0, nb_segs 1, pkt_len 7634
> buf_len 9344, data_len 7634, ol_flags 0x182, data_off 128, phys_addr 
> 0x744c6440
> packet_type 0x2e1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x678c0829 fdir.hi 0x0 fdir.lo 0x678c0829
> Packet Offload Flags
>   PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
>   PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>   PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   RTE_PTYPE_L3_IPV6_EXT_UNKNOWN (0x00e0) IPv6 packet with or without 
> extension headers
>   RTE_PTYPE_L4_UDP (0x0200) UDP packet
>   IP6: b8:83:03:79:9f:e8 -> b8:83:03:79:af:8c 802.1q vlan 2001
>   UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
> tos 0x00, flow label 0x0, hop limit 64, payload length 7576
>   UDP: 23456 -> 9915
> length 7576, checksum 0x225d
> 01:12:04:676154: ethernet-input
>   frame: flags 0x3, hw-if-index 2, sw-if-index 2
>   IP6: b8:83:03:79:9f:e8 -> b8:83:03:79:af:8c 802.1q vlan 2001
> 01:12:04:676156: ip6-input
>   UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
> tos 0x00, flow label 0x0, hop limit 64, payload length 7576
>   UDP: 23456 -> 9915
> length 7576, checksum 0x225d
> 01:12:04:676164: ip6-lookup
>   fib 0 dpo-idx 20 flow hash: 0x
>   UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
> tos 0x00, flow label 0x0, hop limit 64, payload length 7576
>   UDP: 23456 -> 9915
> length 7576, checksum 0x225d
> 01:12:04:676166: ip6-local
> UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
>   tos 0x00, flow label 0x0, hop limit 64, payload length 7576
> UDP: 23456 -> 9915
>   length 7576, checksum 0x225d
> 01:12:04:676169: ip6-udp-lookup
>   UDP: src-port 23456 dst-port 9915
> 01:12:04:676169: i

Re: [vpp-dev] TLS configuration & throughput

[Florin Coras]

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 throughput, it seems a bit low. If you manage to get 
the test to work again, try to “clear run; show run” and see the number of 
loops/s reported by the active worker. If the number is low (under 100k) it 
might be that the cpu is not fast enough for both tcp + tls. Things might 
improve after the scheduling improvements (will eventually publish a patch for 
that). 

Regards,
Florin

> On Feb 26, 2020, at 11:46 AM, dchons via Lists.Fd.Io 
>  wrote:
> 
> 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.89 Gbps) but 
> hey, 3x improvement is a great start ;-)
> 
> FYI the server-side VPP instance crashed at the end of the test and I didn't 
> get a chance to collect anything.
> 
> The rest of the email below is from what I was typing before the test worked 
> (I didn't do anything differently that I am aware of...).
> 
> Regards,
> Dom
> 
> --- From failed test runs: --
> The iperf client indicates that it is connected, but basically just sits 
> there until I stop it with Ctrl-C:
> 
> # LD_PRELOAD=$LDP_PATH VCL_CONFIG=$VCL_CFG taskset --cpu-list 4,6,8 iperf3 -c 
> 10.0.0.71
> Connecting to host 10.0.0.71, port 5201
> [ 33] local 10.0.0.70 port 37502 connected to 10.0.0.71 port 5201
> 
> VPP session info:
> Client side:
> vpp# sh session verbose
> Thread 0: no sessions
>
> ConnectionState  Rx-f  
> Tx-f
> [1:0][T] 10.0.0.70:37502->10.0.0.71:5201  ESTABLISHED0 0
> [1:1][TLS] app_wrk 2 index 0 engine 1 tcp 1:0 ESTABLISHED0 0
> [1:2][T] 10.0.0.70:6875->10.0.0.71:5201   ESTABLISHED0 0
> [1:3][TLS] app_wrk 2 index 1 engine 1 tcp 1:2 ESTABLISHED0 0
> Thread 1: active sessions 4
> Thread 2: no sessions
> Thread 3: no sessions
> Thread 4: no sessions
> 
> Server side:
> vpp# sh session verbose
> ConnectionState  Rx-f  
> Tx-f
> [0:0][TLS] app_wrk 2 engine 1 tcp 0:1 LISTEN 0 0
> [0:1][T] 10.0.0.71:5201->0.0.0.0:0LISTEN 0 0
> Thread 0: active sessions 2
>
> ConnectionState  Rx-f  
> Tx-f
> [1:0][T] 10.0.0.71:5201->10.0.0.70:6875   ESTABLISHED0 0
> [1:1][TLS] app_wrk 2 index 0 engine 1 tcp 1:0 ESTABLISHED0 0
> [1:2][T] 10.0.0.71:5201->10.0.0.70:37502  ESTABLISHED0 0
> [1:3][TLS] app_wrk 2 index 1 engine 1 tcp 1:2 ESTABLISHED0 0
> Thread 1: active sessions 4
> Thread 2: no sessions
> Thread 3: no sessions
> Thread 4: no sessions
> Thread 5: no sessions
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15571): https://lists.fd.io/g/vpp-dev/message/15571
Mute This Topic: https://lists.fd.io/mt/71542617/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Multiple UDP receiver applications on same port #vpp-hoststack

[Raj Kumar]

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 also start receiving the 
traffic.

vpp# sh ip6 int

vppnet1.2001 is admin up

Local unicast address(es):

fd0d:edc4::2001::213/64

fd0d:edc4::2001::223/64

Link-local address(es):

fe80::ba83:3ff:fe79:af8c

When both applications are running : -
vpp# sh session verbose 1
Connection                                        State          Rx-f      Tx-f
[#0][U] fd0d:edc4::2001::213:9915->:::0       -              0         0
[#0][U] fd0d:edc4::2001::223:9915->:::0       -              0         0
Thread 0: active sessions 2
Thread 1: no sessions
Thread 2: no sessions
Thread 3: no sessions
Thread 4: no sessions

Connection                                        State          Rx-f      Tx-f
[#5][U] fd0d:edc4::2001::213:9915->fd0d:edc4:f-              15226     0
Thread 5: active sessions 1

Connection                                        State          Rx-f      Tx-f
[#6][U] fd0d:edc4::2001::223:9915->fd0d:edc4:f-              0         0
Thread 6: active sessions 1

On stopping first application  : -

vpp# sh session verbose 1

Connection                                        State          Rx-f      Tx-f

[#0][U] fd0d:edc4::2001::223:9915->:::0       -              0         0

Thread 0: active sessions 1

Thread 1: no sessions

Thread 2: no sessions

Thread 3: no sessions

Thread 4: no sessions

Thread 5: no sessions

Connection                                        State          Rx-f      Tx-f

[#6][U] fd0d:edc4::2001::223:9915->fd0d:edc4:f-              0         0

Thread 6: active sessions 1

One active session is there but in 'sh err'  "no listener punt" error 
increments and application is not receiving the data.

310150540             ip6-udp-lookup             no listener punt

packet trace :-

--- Start of thread 6 vpp_wk_5 ---
Packet 1

01:12:04:676114: dpdk-input
vppnet1 rx queue 2
buffer 0x10b18f: current data 0, length 7634, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x600
ext-hdr-valid
PKT MBUF: port 0, nb_segs 1, pkt_len 7634
buf_len 9344, data_len 7634, ol_flags 0x182, data_off 128, phys_addr 0x744c6440
packet_type 0x2e1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x678c0829 fdir.hi 0x0 fdir.lo 0x678c0829
Packet Offload Flags
PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
RTE_PTYPE_L3_IPV6_EXT_UNKNOWN (0x00e0) IPv6 packet with or without extension 
headers
RTE_PTYPE_L4_UDP (0x0200) UDP packet
IP6: b8:83:03:79:9f:e8 -> b8:83:03:79:af:8c 802.1q vlan 2001
UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
tos 0x00, flow label 0x0, hop limit 64, payload length 7576
UDP: 23456 -> 9915
length 7576, checksum 0x225d
01:12:04:676154: ethernet-input
frame: flags 0x3, hw-if-index 2, sw-if-index 2
IP6: b8:83:03:79:9f:e8 -> b8:83:03:79:af:8c 802.1q vlan 2001
01:12:04:676156: ip6-input
UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
tos 0x00, flow label 0x0, hop limit 64, payload length 7576
UDP: 23456 -> 9915
length 7576, checksum 0x225d
01:12:04:676164: ip6-lookup
fib 0 dpo-idx 20 flow hash: 0x
UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
tos 0x00, flow label 0x0, hop limit 64, payload length 7576
UDP: 23456 -> 9915
length 7576, checksum 0x225d
01:12:04:676166: ip6-local
UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
tos 0x00, flow label 0x0, hop limit 64, payload length 7576
UDP: 23456 -> 9915
length 7576, checksum 0x225d
01:12:04:676169: ip6-udp-lookup
UDP: src-port 23456 dst-port 9915
01:12:04:676169: ip6-punt
UDP: fd0d:edc4::2001::104 -> fd0d:edc4::2001::223
tos 0x00, flow label 0x0, hop limit 64, payload length 7576
UDP: 23456 -> 9915
length 7576, checksum 0x225d
01:12:04:676169: error-punt
rx:vppnet1.2001
01:12:04:676170: punt
ip6-udp-lookup: no listener punt

thanks,
-Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15570): https://lists.fd.io/g/vpp-dev/message/15570
Mute This Topic: https://lists.fd.io/mt/71574152/21656
Mute #vpp-hoststack: https://lists.fd.io/mk?hashtag=vpp-hoststack&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Error: esp4-encrypt-tun-handoff : congestion drop #ipsec

[ravinder . yadav]

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-udp-lookup             no error
19061984            esp4-decrypt-tun            ESP pkts received
1            esp4-decrypt-tun            Integrity check failed
134757254            esp4-encrypt-tun            ESP pkts received
19061984            ipsec4-tun-input            good packets received
*33913        esp4-encrypt-tun-handoff        congestion drop*
31                ip4-glean               ARP requests sent
263             ethernet-input             no error

-Ravin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15569): https://lists.fd.io/g/vpp-dev/message/15569
Mute This Topic: https://lists.fd.io/mt/71573632/21656
Mute #ipsec: https://lists.fd.io/mk?hashtag=ipsec&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] TLS configuration & throughput

[dchons via Lists.Fd.Io]

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.89 Gbps) but hey, 3x 
improvement is a great start ;-)

FYI the server-side VPP instance crashed at the end of the test and I didn't 
get a chance to collect anything.

The rest of the email below is from what I was typing before the test worked (I 
didn't do anything differently that I am aware of...).

Regards,
Dom

--- From failed test runs: --
The iperf client indicates that it is connected, but basically just sits there 
until I stop it with Ctrl-C:

# LD_PRELOAD=$LDP_PATH VCL_CONFIG=$VCL_CFG taskset --cpu-list 4,6,8 iperf3 -c 
10.0.0.71
Connecting to host 10.0.0.71, port 5201
[ 33] local 10.0.0.70 port 37502 connected to 10.0.0.71 port 5201

*VPP session info:
Client side:*
vpp# sh session verbose
Thread 0: no sessions

Connection                                        State          Rx-f      Tx-f
[1:0][T] 10.0.0.70:37502->10.0.0.71:5201          ESTABLISHED    0         0
[1:1][TLS] app_wrk 2 index 0 engine 1 tcp 1:0     ESTABLISHED    0         0
[1:2][T] 10.0.0.70:6875->10.0.0.71:5201           ESTABLISHED    0         0
[1:3][TLS] app_wrk 2 index 1 engine 1 tcp 1:2     ESTABLISHED    0         0
Thread 1: active sessions 4
Thread 2: no sessions
Thread 3: no sessions
Thread 4: no sessions

*Server side:*
vpp# sh session verbose
Connection                                        State          Rx-f      Tx-f
[0:0][TLS] app_wrk 2 engine 1 tcp 0:1             LISTEN         0         0
[0:1][T] 10.0.0.71:5201->0.0.0.0:0                LISTEN         0         0
Thread 0: active sessions 2

Connection                                        State          Rx-f      Tx-f
[1:0][T] 10.0.0.71:5201->10.0.0.70:6875           ESTABLISHED    0         0
[1:1][TLS] app_wrk 2 index 0 engine 1 tcp 1:0     ESTABLISHED    0         0
[1:2][T] 10.0.0.71:5201->10.0.0.70:37502          ESTABLISHED    0         0
[1:3][TLS] app_wrk 2 index 1 engine 1 tcp 1:2     ESTABLISHED    0         0
Thread 1: active sessions 4
Thread 2: no sessions
Thread 3: no sessions
Thread 4: no sessions
Thread 5: no sessions
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15568): https://lists.fd.io/g/vpp-dev/message/15568
Mute This Topic: https://lists.fd.io/mt/71542617/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP IPSec Responder Server (VPN Server) VPP Route injection

[ravinder . yadav]

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 to add a route for remote ip 
range.

*Case # When you have more than two IPSec, the ipsec interface name depends on 
which tunnels got established first.*
ipip0 interface (Can't add route because don't know which remote ip range): 
Could be remote 1 or 2
ipip1 interface (Can't add route because don't know which remote ip range): 
Could be remote 1 or 2

This becomes a big issue when you have 250 clients coming in at the same time. 
It become impossible to decide which route gets injected on which interface!!

-Ravin

Ref: 
https://wiki.fd.io/view/VPP/IPSec_and_IKEv2#Routing_traffic_through_ipsec0_interface_on_the_VPP_responder

Routing traffic through ipsec0 interface on the VPP responder

At this point of the configuration, you still do not have end to end secure 
connectivity. You need to route traffic through ipsec0 created interface on 
VPP. There are two ways of doing it.

First: using a dummy IP address.

set interface state ipsec0 up
set interface ip address ipsec0 11.11.11.11/32
ip route add 192.168.3.0/24 via 11.11.11.11 ipsec0

Second: binding logical and physical interfaces

You must use tunnel endpoint interface.

ip route add 192.168.3.0/24 via ipsec0
set interface state ipsec0 up
set interface unnumbered ipsec0 use TenGigabitEthernet4/0/0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15567): https://lists.fd.io/g/vpp-dev/message/15567
Mute This Topic: https://lists.fd.io/mt/71571955/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP Plugins build errors from IPSec module

[Majumdar, Kausik]

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 the same issue is being discussed in the 
past. Hopefully we can get a resolution on this.

Yes, I can volunteer to put together the steps in an email or wiki if once I am 
able to bring-up VPP with FRR.

Thanks,
Kausik

From: Chuan Han 
Sent: Wednesday, February 26, 2020 7:43 AM
To: Ray Kinsella 
Cc: Majumdar, Kausik ; vpp-dev 
; vppsb-...@lists.fd.io
Subject: Re: [vpp-dev] VPP Plugins build errors from IPSec module

Message received from external source. Exercise caution when opening 
attachments, clicking links, or exchanging information.

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 
mailto:m...@ashroe.eu>> wrote:


I am not sure how accurate / current the information from the wiki is.

However looks like you are missing the Intel Multi-buffer Crypto Library.
Try a `make install-ext-deps`, then wipe and rebuild.

Ray K

On 25/02/2020 22:34, Majumdar, Kausik wrote:
> Hi folks,
>
>
>
> I am trying to build VPP netlink and router plugins based on vpp branch 
> v20.01 to integrate and run with routing control plane FRR. I am following 
> the guidelines based on 
> https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP
>
>
>
> I am finding issues while trying to compile the IPSec plugin code, it is 
> exiting with the below error. I have tried with latest VPP master branch, the 
> result is pretty much same. Is there any resolution to this issue or am I 
> missing something? If I try to use VPP v18.10 branch then I hit other netlink 
> issue which I think discussed in this thread in the past. Hence moved to 
> latest VPP code base, tried to link VPPSB and build the netlink-install and 
> router-install plugins, hitting IPSec build failures. Any recommendation 
> would be helpful.
>
>
>
> I am running Centos 7.4 machine.
>
>
>
> [root@localhost build-root]# git branch
>
> * (detached from v20.01)
>
>   master
>
>
>
> [root@localhost build-root]# *make V=0 PLATFORM=vpp TAG=vpp_debug 
> netlink-install router-install*
>
>  Arch for platform 'vpp' is native 
>
>  Finding source for external 
>
>  Makefile fragment found in 
> /root/vpp/build-data/packages/external.mk
>  
>
>  Source found in /root/vpp/build 
>
>  Arch for platform 'vpp' is native 
>
>  Finding source for vpp 
>
>  Makefile fragment found in 
> /root/vpp/build-data/packages/vpp.mk
>  
>
>  Source found in /root/vpp/src 
>
>  Arch for platform 'vpp' is native 
>
>  Finding source for netlink 
>
>  Makefile fragment found in 
> /root/vpp/build-data/packages/netlink.mk
>  
>
>  Source found in /root/vpp/netlink 
>
>  Configuring external: nothing to do 
>
>  Building external: nothing to do 
>
>  Installing external: nothing to do 
>
>  Configuring vpp: nothing to do 
>
>  Building vpp in /root/vpp/build-root/build-vpp_debug-native/vpp 
>
> [1/660] Building C object 
> plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o
>
> F

Re: [vpp-dev] Change interface default MTU to 1500

[Christian Hopps]

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. :)

With that in mind, a local config default override seems better than a compiled 
default change.

Thanks,
Chris.

> On Feb 26, 2020, at 10:07 AM, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> 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 Barach (dbarach) ; vpp-dev 
> Subject: RE: Change interface default MTU to 1500
>
> 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 changing it to 1500.
>
> Regards,
> John
>
> From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
> Lists.Fd.Io
> Sent: Wednesday, February 26, 2020 8:40 AM
> To: vpp-dev 
> Cc: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Change interface default MTU to 1500
>
> 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 remembers why we’re setting the default 
> MTU to 9000.
>
> Thanks... Dave 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15565): https://lists.fd.io/g/vpp-dev/message/15565
Mute This Topic: https://lists.fd.io/mt/71565329/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Dave Wallace]

+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….

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 from ALL voting jobs.

This MAY lead to an increase in manual rechecks if we see spike of intermittent 
job failures.   But IMO that should not be a large
percentage increase currently without those connection reset issues.

Please let me know if anyone feels that we should keep the retry mechanic in 
place otherwise ill be putting up a ci-management patch
later today for its removal.

thanks,

Ed







On Feb 26, 2020, at 8:08 AM, otr...@employees.org wrote:

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.







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15564): https://lists.fd.io/g/vpp-dev/message/15564
Mute This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] TLS configuration & throughput

[Florin Coras]

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 
> ldp.crt
> 
> Confirmed settings as per [1] above and applied [2] and recompiled. Did a 
> first run without LDP_TRANSPARENT to confirm all other settings:
> 
> # LD_PRELOAD=$LDP_PATH VCL_CONFIG=$VCL_CFG taskset --cpu-list 4,6,8 iperf3 -s 
> -B 10.0.0.71
> ---
> Server listening on 5201
> ---
> Accepted connection from 10.0.0.70, port 11960
> [ 34] local 10.0.0.71 port 5201 connected to 10.0.0.70 port 41655
> [ ID] Interval   Transfer Bandwidth
> [ 34]   0.00-1.00   sec  1.09 GBytes  9.40 Gbits/sec
> [ 34]   1.00-2.00   sec  1.10 GBytes  9.41 Gbits/sec
> [ 34]   2.00-3.00   sec  1.10 GBytes  9.41 Gbits/sec
> [ 34]   3.00-4.00   sec  1.10 GBytes  9.41 Gbits/sec
> [ 34]   4.00-5.00   sec  1.10 GBytes  9.41 Gbits/sec
> [ 34]   5.00-6.00   sec  1.10 GBytes  9.41 Gbits/sec
> [ 34]   6.00-7.00   sec  1.10 GBytes  9.41 Gbits/sec
> [ 34]   7.00-8.00   sec  1.10 GBytes  9.41 Gbits/sec
> [ 34]   8.00-9.00   sec  1.10 GBytes  9.41 Gbits/sec
> [ 34]   9.00-10.00  sec  1.10 GBytes  9.41 Gbits/sec
> [ 34]  10.00-10.00  sec  1.24 MBytes  9.33 Gbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bandwidth
> [ 34]   0.00-10.00  sec  0.00 Bytes  0.00 bits/sec  sender
> [ 34]   0.00-10.00  sec  11.0 GBytes  9.41 Gbits/sec  receiver
> ---
> Server listening on 5201
> ---
> 
> Now set LDP_TRANSPARENT and confirm (on both nodes):
> # export LDP_TRANSPARENT_TLS=1
> # env | grep LDP_
> LDP_TLS_CERT_FILE=/root/tlstest/ldp.crt
> LDP_TRANSPARENT_TLS=1
> LDP_PATH=/root/vpp.20.01/build-root/build-vpp-native/vpp/lib/libvcl_ldpreload.so
> LDP_TLS_KEY_FILE=/root/tlstest/ldp.key
> #
> 
> Re-started & configured VPP to have a clean run, and get this (server side 
> output):
> 
> # LD_PRELOAD=$LDP_PATH VCL_CONFIG=$VCL_CFG taskset --cpu-list 4,6,8 iperf3 -s 
> -B 10.0.0.71
> ---
> Server listening on 5201
> ---
> Accepted connection from 10.0.0.70, port 40411
> [ 34] local 10.0.0.71 port 5201 connected to 10.0.0.70 port 14718
> [ ID] Interval   Transfer Bandwidth
> [ 34]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec
> [ 34]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec
> [ 34]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec
> [ 34]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec
> [ 34]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec
> [ 34]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec
> [ 34]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec
> [ 34]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec
> [ 34]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec
> [ 34]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec
> [ 34]  10.00-11.00  sec  0.00 Bytes  0.00 bits/sec
> [ 34]  11.00-12.00  sec  0.00 Bytes  0.00 bits/sec
> [ 34]  12.00-13.00  sec  0.00 Bytes  0.00 bits/sec
> [ 34]  13.00-14.00  sec  0.00 Bytes  0.00 bits/sec
> [ 34]  14.00-15.00  sec  0.00 Bytes  0.00 bits/sec
> 
> I've tried multiple times, always the same result, the connection seems to be 
> established but no traffic getting through. Here's some output from the 
> server side VPP instance, not sure if there is anything useful in there, I 
> couldn't see anything of interest.
> 
> Thank again for trying it out and for your suggestions!
> 
> Regards,
> Dom
> 
> 
> 
> vpp# sh int
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
> Counter  Count
> TenGigabitEthernet5/0/0   1  up  9000/0/0/0 rx 
> packets22
> rx bytes  
>   2263
> tx 
> packets13
> tx bytes  
>   4042
> drops 
>  5
> ip4   
> 17
> local00 down  0/0/0/0  

Re: [vpp-dev] TLS configuration & throughput

[dchons via Lists.Fd.Io]

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 
ldp.crt*

Confirmed settings as per [1] above and applied [2] and recompiled. Did a first 
run *without* LDP_TRANSPARENT to confirm all other settings:

# LD_PRELOAD=$LDP_PATH VCL_CONFIG=$VCL_CFG taskset --cpu-list 4,6,8 iperf3 -s 
-B 10.0.0.71
---
Server listening on 5201
---
Accepted connection from 10.0.0.70, port 11960
[ 34] local 10.0.0.71 port 5201 connected to 10.0.0.70 port 41655
[ ID] Interval           Transfer     Bandwidth
[ 34]   0.00-1.00   sec  1.09 GBytes  9.40 Gbits/sec
[ 34]   1.00-2.00   sec  1.10 GBytes  9.41 Gbits/sec
[ 34]   2.00-3.00   sec  1.10 GBytes  9.41 Gbits/sec
[ 34]   3.00-4.00   sec  1.10 GBytes  9.41 Gbits/sec
[ 34]   4.00-5.00   sec  1.10 GBytes  9.41 Gbits/sec
[ 34]   5.00-6.00   sec  1.10 GBytes  9.41 Gbits/sec
[ 34]   6.00-7.00   sec  1.10 GBytes  9.41 Gbits/sec
[ 34]   7.00-8.00   sec  1.10 GBytes  9.41 Gbits/sec
[ 34]   8.00-9.00   sec  1.10 GBytes  9.41 Gbits/sec
[ 34]   9.00-10.00  sec  1.10 GBytes  9.41 Gbits/sec
[ 34]  10.00-10.00  sec  1.24 MBytes  9.33 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[ 34]   0.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 34]   0.00-10.00  sec  11.0 GBytes  9.41 Gbits/sec                  receiver
---
Server listening on 5201
---

Now set LDP_TRANSPARENT and confirm (on both nodes):
# export LDP_TRANSPARENT_TLS=1
# env | grep LDP_
LDP_TLS_CERT_FILE=/root/tlstest/ldp.crt
LDP_TRANSPARENT_TLS=1
LDP_PATH=/root/vpp.20.01/build-root/build-vpp-native/vpp/lib/libvcl_ldpreload.so
LDP_TLS_KEY_FILE=/root/tlstest/ldp.key
#

Re-started & configured VPP to have a clean run, and get this (server side 
output):

# LD_PRELOAD=$LDP_PATH VCL_CONFIG=$VCL_CFG taskset --cpu-list 4,6,8 iperf3 -s 
-B 10.0.0.71
---
Server listening on 5201
---
Accepted connection from 10.0.0.70, port 40411
[ 34] local 10.0.0.71 port 5201 connected to 10.0.0.70 port 14718
[ ID] Interval           Transfer     Bandwidth
[ 34]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec
[ 34]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec
[ 34]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec
[ 34]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec
[ 34]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec
[ 34]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec
[ 34]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec
[ 34]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec
[ 34]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec
[ 34]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec
[ 34]  10.00-11.00  sec  0.00 Bytes  0.00 bits/sec
[ 34]  11.00-12.00  sec  0.00 Bytes  0.00 bits/sec
[ 34]  12.00-13.00  sec  0.00 Bytes  0.00 bits/sec
[ 34]  13.00-14.00  sec  0.00 Bytes  0.00 bits/sec
[ 34]  14.00-15.00  sec  0.00 Bytes  0.00 bits/sec

I've tried multiple times, always the same result, the connection seems to be 
established but no traffic getting through. Here's some output from the server 
side VPP instance, not sure if there is anything useful in there, I couldn't 
see anything of interest.

Thank again for trying it out and for your suggestions!

Regards,
Dom

vpp# sh int
Name               Idx    State  MTU (L3/IP4/IP6/MPLS)     Counter          
Count
TenGigabitEthernet5/0/0           1      up          9000/0/0/0     rx packets  
                  22
rx bytes                    2263
tx packets                    13
tx bytes                    4042
drops                          5
ip4                           17
local0                            0     down          0/0/0/0       drops       
                   2
vpp# sh err
Count                    Node                  Reason
1               dpdk-input               no error
10              session-queue             Packets transmitted
2               tcp4-listen              SYNs received
1            tcp4-rcv-process            SYNs received
2            tcp4-rcv-process            Pure ACKs received
7            tcp4-established            Packets pushed into rx fifo
5            tcp4-established            Pure ACKs received
14               tcp4-output              Packets sent
1                ip4-glean               ARP requests throttled
1                ip4-glean               ARP requests sent
6                llc-input               unknown llc ssap/dsap
vpp# sh hardware-interfaces
Name                Idx   Link  Hardware
TenGigabitEthernet5/0/0            1     up  

[vpp-dev] gtpu: breaking changes proposal: support different source and destination TEIDs

[Nick Zavaritsky]

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_if_index;
u32 encap_vrf_id;
u32 decap_next_index;
-  u32 teid;
-  option vat_help = "src  { dst  | group  { 
 | mcast_sw_if_index  } } teid  [encap-vrf-id ] 
[decap-next ] [del]";
+  u32 src_teid;
+  u32 dst_teid;
+  option vat_help = "src  { dst  | group  { 
 | mcast_sw_if_index  } } src-teid  dst-teid  
[encap-vrf-id ] [decap-next ] [del]";
};

Prior to submitting the patch I'd like to find out if it affects other people 
using GTPU and what would be the preferred way forward.

Best,
Nick
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15561): https://lists.fd.io/g/vpp-dev/message/15561
Mute This Topic: https://lists.fd.io/mt/71569677/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VRF-aware bypass nodes

[Nick Zavaritsky]

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 
address and UDP destination port equal to 2152.

Bypass node MUST NOT intercept a packet if destination IP doesn’t match a local 
address. Otherwise enabling GTPU bypass would change the observable system 
behaviour.

An address is local within a certain VRF. It’s possible that an address is 
local in one VRF but it’s not in another. But GTPU bypass node is not VRF aware.

Image a vpp setup with 2 interfaces, associated with different VRF-s. The first 
interface address is 10.0.10.100, the other one — 192.168.0.7. Both have GTPU 
bypass enabled. Now GTPU bypass in the second interface will intercept packets 
sent to 10.0.10.100 (the first interface’s address), though it shouldn’t.

This is a somewhat contrived example, but it looks like bypass node should be 
VRF-aware for correctness.

Am I missing something?

Would you be open to a patch making GTPU bypass VRF-aware?

Best,
Nick
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15560): https://lists.fd.io/g/vpp-dev/message/15560
Mute This Topic: https://lists.fd.io/mt/71569502/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches?

[Andrew Yourtchenko]

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, right ?

--a

> On 26 Feb 2020, at 17:26, Vratko Polak -X (vrpolak - PANTHEON TECH SRO at 
> Cisco)  wrote:
> 
> 
> > 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@lists.fd.io  On Behalf Of Andrew 
> Yourtchenko
> Sent: Tuesday, February 25, 2020 6:49 PM
> To: Dave Barach (dbarach) 
> Cc: Christian Hopps ; vpp-dev ; 
> vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. 
> release branches?
>  
> With my 19.08 release manager hat on,
> For the current state of the matters my view is “as soon as the CRC of any 
> existing messages does not change, a patch is okay to include into 19.08”.
>  
> This applies recursively, meaning that if one add a new message to 1908, it 
> comes in as “frozen” with no further changes. Why ? Because if it is not 
> perfect API wise it’s not stable, it should first settle down on master.
>  
> That’s the logic I had been using so far.
>  
> I am currently working on an 19.08 api translation layer  experiment that in 
> principle should allow more freedom... but till that is successful that is my 
> point of view. Unless the community decides otherwise, of course.
>  
> --a
> 
> 
> On 25 Feb 2020, at 16:56, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> 
> Dear Chris,
>  
> Adding missing flags to ipsec_sad_flags shouldn’t break much of anything. 
> Never say never, but for me, I wouldn’t hesitate to merge such a patch.
>  
> Adding an entirely new message will renumber subsequent core engine messages, 
> and implies client recompilation. My $0.02: again, not such a big deal.
>  
> What do other people think?
>  
> Dave
>  
> P.S. in master/latest, enum ipsec_sad_flags has moved to 
> .../src/vnet/ipsec/ipsec_types.api...
>  
>  
> From: vpp-dev@lists.fd.io  On Behalf Of Christian Hopps
> Sent: Tuesday, February 25, 2020 10:25 AM
> To: vpp-dev 
> Cc: Christian Hopps 
> Subject: [vpp-dev] Can I submit some API changes for 19.08, et al. release 
> branches?
>  
> I've got a couple of changes to the ipsec API that I'd like to upstream to 
> match the vpp "kernel" code I'm going try and upstream to strongswan.
> 
> 1) Add: Add an ip_route_lookup/reply pair (semver minor++)
> 2) Fix: Add IS_INBOUND flag (value 0x40) to ipsec_sad_flags (semver patch++)
> optional) Fix: possibly add the other missing flags to ipsec_sad_flags so 
> they can be properly returned on queries.
> 
> I think submitting these for release branches is OK after reading 
> https://wiki.fd.io/view/VPP/API_Versioning
> 
> I'm coding to 19.08 right now, if I'd like to have those changes in that 
> branch I would imagine I'd need to also submit changes for 20.01 and master?
> 
> I admit to being confused about the CRC stuff, and the warnings in the 
> 19.08.1 release notes and what those warnings imply. Is it safe to assume the 
> CRC stuff can be ignored and external clients will still work (given no 
> semver major change) even if a CRC chagnes?
> 
> Side Note: from the API link: "If a new message type is added, the old 
> message type must be maintained for at least one release. The change must be 
> included in the release notes, and it would be helpful if the message could 
> be tagged as deprecated in the API language and a logging message given to 
> the user."
> 
> Given there are 3 releases per year, only maintaining an old compatible 
> function for 1 release seems rather aggressive. It does say "at least" 
> though. :)
> 
> Thanks,
> Chris.
> 
>  
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15559): https://lists.fd.io/g/vpp-dev/message/15559
Mute This Topic: https://lists.fd.io/mt/71535081/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP Plugins build errors from IPSec module

[Neale Ranns via Lists.Fd.Io]

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 package and installed it. The vpp process comes up. Currently, the built 
errors are bit different, netlink lib built is failing. Also, I see the same 
issue being discussed earlier in the vpp-dev mailing alias, but not sure what 
was the solution. I have seen the same issue with latest vpp and v18.10 code 
base.

Please suggest me any recommendation here.

Thanks,
Kausik

/root/vpp/build-data/../netlink/librtnl/netns.c:69:5: error: 'RTA_VIA' 
undeclared here (not in a function)
   _(RTA_VIA, via, 1)\
 ^
/root/vpp/build-data/../netlink/librtnl/rtnl.c:269:39: error: 
'RTNLGRP_MPLS_ROUTE' undeclared (first use in this function)
 grpmask(RTNLGRP_NOTIFY) | grpmask(RTNLGRP_MPLS_ROUTE),
   ^

1. The netlink and router plugins failed to built due to the below errors:

[root@localhost vpp]# ln -sf /home/vagrant/vppsb/netlink
[root@localhost vpp]# ln -sf /home/vagrant/vppsb/router
[root@localhost vpp]# ln -sf ../../netlink/netlink.mk build-data/packages/
[root@localhost vpp]# ln -sf ../../router/router.mk build-data/packages/
[root@localhost vpp]# cd build-root/
 [root@localhost build-root]# git branch
* (detached from v20.01)
  master
[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install
 Arch for platform 'vpp' is native 
 Finding source for external 
 Makefile fragment found in /root/vpp/build-data/packages/external.mk 

 Source found in /root/vpp/build 
 Arch for platform 'vpp' is native 
 Finding source for vpp 
 Makefile fragment found in /root/vpp/build-data/packages/vpp.mk 
 Source found in /root/vpp/src 
 Arch for platform 'vpp' is native 
 Finding source for netlink 
 Makefile fragment found in /root/vpp/build-data/packages/netlink.mk 

 Source found in /root/vpp/netlink 
 Configuring external: nothing to do 
 Building external: nothing to do 
 Installing external: nothing to do 
 Configuring vpp: nothing to do 
 Building vpp in /root/vpp/build-root/build-vpp_debug-native/vpp 
ninja: no work to do.
 Installing vpp: nothing to do 
 Configuring netlink: nothing to do 
 Building netlink in 
/root/vpp/build-root/build-vpp_debug-native/netlink 
make[1]: Entering directory 
`/root/vpp/build-root/build-vpp_debug-native/netlink'
  CC   librtnl/rtnl.lo
  CC   librtnl/netns.lo
/root/vpp/build-data/../netlink/librtnl/netns.c:69:5: error: 'RTA_VIA' 
undeclared here (not in a function)
   _(RTA_VIA, via, 1)\
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:82:13: note: in definition 
of macro '_'
 .type = t, .unique = u, \
 ^
/root/vpp/build-data/../netlink/librtnl/netns.c:86:3: note: in expansion of 
macro 'ns_foreach_rta'
   ns_foreach_rta
   ^
/root/vpp/build-data/../netlink/librtnl/rtnl.c: In f[root@localhost vpp]# 
ln -sf /home/vagrant/vppsb/netlink
[root@localhost vpp]# ln -sf /home/vagrant/vppsb/router
[root@localhost vpp]# ln -sf ../../netlink/netlink.mk build-data/packages/
[root@localhost vpp]# ln -sf ../../router/router.mk build-data/packages/
[root@localhost vpp]# cd build-root/
[root@localhost build-root]# ls
a   gcm##b##_pre  
vpp-20.01-release.x86_64.rpm
aes_gcm_pre hash_fn   
vpp-api-lua-20.01-release.x86_64.rpm
autowankinstall-vpp_debug-native  
vpp-api-python-20.01-release.x86_64.rpm
build-config.mk install-vpp-native
vpp-api-python3-20.01-release.x86_64.rpm
build-config.mk.README  Makefile  
vpp-debuginfo-20.01-release.x86_64.rpm
build-vpp_debug-native  platforms.mk  
vpp-devel-20.01-release.x86_64.rpm
build-vpp-nativerpmbuild  vpp-latest.tar.xz
c   scripts   
vpp-lib-20.01-release.x86_64.rpm
config.site vagrant   
vpp-plugins-20.01-release.x86_64.rpm
copyimg vpp-20.01-release.tar.xz  
vpp-selinux-policy-20.01-release.x86_64.rpm
[root@localhost build-root]# git branch
* (detached from v20.01)
  master
[root@localhost build-root]# make V=0 PLATFORM=vpp TAG=vpp_debug 
netlink-install router-install
 Arch for platform 'vpp' is native @@

Re: [vpp-dev] TLS configuration & throughput

[Florin Coras]

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, probably because tls 
might return some partial data.

After this patch [2], in my testbed running 2 Xeon Gold 6146, I’m seeing this:

Connecting to host 6.0.1.1, port 5201
[ 33] local 6.0.1.2 port 12620 connected to 6.0.1.1 port 5201
[ ID] Interval   Transfer Bandwidth   Retr  Cwnd
[ 33]   0.00-1.00   sec  1.56 GBytes  13.4 Gbits/sec0   0.00 Bytes
[ 33]   1.00-2.00   sec  1.57 GBytes  13.5 Gbits/sec0   0.00 Bytes
[ 33]   2.00-3.00   sec  1.57 GBytes  13.5 Gbits/sec0   0.00 Bytes 
…
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[ 33]   0.00-30.00  sec  47.2 GBytes  13.5 Gbits/sec0 sender
[ 33]   0.00-30.00  sec  47.2 GBytes  13.5 Gbits/sec  receiver

Regards,
Florin

[1] https://wiki.fd.io/view/VPP/HostStack/LDP/iperf 

[2] https://gerrit.fd.io/r/c/vpp/+/25477 


> On Feb 25, 2020, at 4:15 PM, dchons via Lists.Fd.Io 
>  wrote:
> 
> Hi Florin,
> 
> Thank you for your response. I used different rx/tx buffer sizes and it 
> didn't really make a difference. For this stage, it's good enough to know 
> that there are known performance limitations, thank you again for your help.
> 
> Regards,
> Dom 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15557): https://lists.fd.io/g/vpp-dev/message/15557
Mute This Topic: https://lists.fd.io/mt/71542617/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

> 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 Barach (dbarach) ; Maciek Konstantynowicz 
(mkonstan) ; vpp-dev ; Jakub Grajciar 
-X (jgrajcia - PANTHEON TECH SRO at Cisco) 
Subject: Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...



> 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] older failures.
>  
> Not sure whether is better to revert the change
> or wait for CSIT to catch up.

How long do we have to wait?
If very long at all, I'd much rather revert 22698.

Cheers,
Ole


>  
> Vratko.
>  
> [0] https://gerrit.fd.io/r/c/vpp/+/22698
> [1] https://lists.fd.io/g/vpp-api-dev/message/32
> [2] https://lists.fd.io/g/vpp-dev/message/11754
>  
> 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 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 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.json files:
> 13:24:04 {
> 13:24:04  "ipsec_interface_add_del_spd":"0x80f80cbb",
> 13:24:04  "ipsec_sad_entry_add_del":"0x57cc13fa",
> 13:24:04  "ipsec_select_backend":"0x5bcfd3b7",
> 13:24:04  "ipsec_spd_add_del":"0x20e89a95",
> 13:24:04  "ipsec_spd_entry_add_del":"0x9f384b8d",
> 13:24:04  "ipsec_tunnel_if_add_del":"0x2b135e68",
> 13:24:04  "ipsec_tunnel_if_add_del_reply":"0x5383d31f"
> 13:24:04 }
> 13:24:04 RuntimeError('Incompatible API CRCs found in .api.json files:\n{\n 
> "ipsec_interface_add_del_spd":"0x80f80cbb",\n 
> "ipsec_sad_entry_add_del":"0x57cc13fa",\n 
> "ipsec_select_backend":"0x5bcfd3b7",\n "ipsec_spd_add_del":"0x20e89a95",\n 
> "ipsec_spd_entry_add_del":"0x9f384b8d",\n 
> "ipsec_tunnel_if_add_del":"0x2b135e68",\n 
> "ipsec_tunnel_if_add_del_reply":"0x5383d31f"\n}',)
>  
>  
> 
> On 26 Feb 2020, at 14:44, Dave Barach (dbarach)  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.
>  
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15556): https://lists.fd.io/g/vpp-dev/message/15556
Mute This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches?

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

> 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@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Andrew 
Yourtchenko
Sent: Tuesday, February 25, 2020 6:49 PM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release 
branches?

With my 19.08 release manager hat on,
For the current state of the matters my view is “as soon as the CRC of any 
existing messages does not change, a patch is okay to include into 19.08”.

This applies recursively, meaning that if one add a new message to 1908, it 
comes in as “frozen” with no further changes. Why ? Because if it is not 
perfect API wise it’s not stable, it should first settle down on master.

That’s the logic I had been using so far.

I am currently working on an 19.08 api translation layer  experiment that in 
principle should allow more freedom... but till that is successful that is my 
point of view. Unless the community decides otherwise, of course.

--a


On 25 Feb 2020, at 16:56, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:

Dear Chris,

Adding missing flags to ipsec_sad_flags shouldn’t break much of anything. Never 
say never, but for me, I wouldn’t hesitate to merge such a patch.

Adding an entirely new message will renumber subsequent core engine messages, 
and implies client recompilation. My $0.02: again, not such a big deal.

What do other people think?

Dave

P.S. in master/latest, enum ipsec_sad_flags has moved to 
.../src/vnet/ipsec/ipsec_types.api...


From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Christian Hopps
Sent: Tuesday, February 25, 2020 10:25 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: Christian Hopps mailto:cho...@chopps.org>>
Subject: [vpp-dev] Can I submit some API changes for 19.08, et al. release 
branches?

I've got a couple of changes to the ipsec API that I'd like to upstream to 
match the vpp "kernel" code I'm going try and upstream to strongswan.

1) Add: Add an ip_route_lookup/reply pair (semver minor++)
2) Fix: Add IS_INBOUND flag (value 0x40) to ipsec_sad_flags (semver patch++)
optional) Fix: possibly add the other missing flags to ipsec_sad_flags so they 
can be properly returned on queries.

I think submitting these for release branches is OK after reading 
https://wiki.fd.io/view/VPP/API_Versioning

I'm coding to 19.08 right now, if I'd like to have those changes in that branch 
I would imagine I'd need to also submit changes for 20.01 and master?

I admit to being confused about the CRC stuff, and the warnings in the 19.08.1 
release notes and what those warnings imply. Is it safe to assume the CRC stuff 
can be ignored and external clients will still work (given no semver major 
change) even if a CRC chagnes?

Side Note: from the API link: "If a new message type is added, the old message 
type must be maintained for at least one release. The change must be included 
in the release notes, and it would be helpful if the message could be tagged as 
deprecated in the API language and a logging message given to the user."

Given there are 3 releases per year, only maintaining an old compatible 
function for 1 release seems rather aggressive. It does say "at least" though. 
:)

Thanks,
Chris.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#1): https://lists.fd.io/g/vpp-dev/message/1
Mute This Topic: https://lists.fd.io/mt/71535081/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Ole Troan]

> 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] older failures.
>
> Not sure whether is better to revert the change
> or wait for CSIT to catch up.

How long do we have to wait?
If very long at all, I'd much rather revert 22698.

Cheers,
Ole


>
> Vratko.
>
> [0] https://gerrit.fd.io/r/c/vpp/+/22698
> [1] https://lists.fd.io/g/vpp-api-dev/message/32
> [2] https://lists.fd.io/g/vpp-dev/message/11754
>
> 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 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 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.json files:
> 13:24:04 {
> 13:24:04  "ipsec_interface_add_del_spd":"0x80f80cbb",
> 13:24:04  "ipsec_sad_entry_add_del":"0x57cc13fa",
> 13:24:04  "ipsec_select_backend":"0x5bcfd3b7",
> 13:24:04  "ipsec_spd_add_del":"0x20e89a95",
> 13:24:04  "ipsec_spd_entry_add_del":"0x9f384b8d",
> 13:24:04  "ipsec_tunnel_if_add_del":"0x2b135e68",
> 13:24:04  "ipsec_tunnel_if_add_del_reply":"0x5383d31f"
> 13:24:04 }
> 13:24:04 RuntimeError('Incompatible API CRCs found in .api.json files:\n{\n 
> "ipsec_interface_add_del_spd":"0x80f80cbb",\n 
> "ipsec_sad_entry_add_del":"0x57cc13fa",\n 
> "ipsec_select_backend":"0x5bcfd3b7",\n "ipsec_spd_add_del":"0x20e89a95",\n 
> "ipsec_spd_entry_add_del":"0x9f384b8d",\n 
> "ipsec_tunnel_if_add_del":"0x2b135e68",\n 
> "ipsec_tunnel_if_add_del_reply":"0x5383d31f"\n}',)
>
>
> 
> On 26 Feb 2020, at 14:44, Dave Barach (dbarach)  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.
>
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15554): https://lists.fd.io/g/vpp-dev/message/15554
Mute This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Change interface default MTU to 1500

[John Lo (loj) via Lists.Fd.Io]

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 to one of the existing config functions.

I'm sick of cluttering configs with interface MTU commands...

Thanks... Dave

From: John Lo (loj) mailto:l...@cisco.com>>
Sent: Wednesday, February 26, 2020 9:47 AM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>; 
vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: RE: Change interface default MTU to 1500

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 changing it to 1500.

Regards,
John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Wednesday, February 26, 2020 8:40 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] Change interface default MTU to 1500


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 remembers why we're setting the default MTU 
to 9000.



Thanks... Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15553): https://lists.fd.io/g/vpp-dev/message/15553
Mute This Topic: https://lists.fd.io/mt/71565329/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Andrew Yourtchenko]

+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 with no jenkins connection issues (one of 
> the main drivers for the retry introduction). Id like
> to propose removing the retry from ALL voting jobs.   
> 
> This MAY lead to an increase in manual rechecks if we see spike of 
> intermittent job failures.   But IMO that should not be a large
> percentage increase currently without those connection reset issues.
> 
> Please let me know if anyone feels that we should keep the retry mechanic in 
> place otherwise ill be putting up a ci-management patch
> later today for its removal.
> 
> thanks,
> 
> Ed
> 
> 
> 
> 
> 
> 
>> On Feb 26, 2020, at 8:08 AM, otr...@employees.org wrote:
>> 
>> 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.
>>> 
>> 
> 
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15552): https://lists.fd.io/g/vpp-dev/message/15552
Mute This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP Plugins build errors from IPSec module

[Chuan Han via Lists.Fd.Io]

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-buffer Crypto Library.
> Try a `make install-ext-deps`, then wipe and rebuild.
>
> Ray K
>
> On 25/02/2020 22:34, Majumdar, Kausik wrote:
> > Hi folks,
> >
> >
> >
> > I am trying to build VPP netlink and router plugins based on vpp branch
> v20.01 to integrate and run with routing control plane FRR. I am following
> the guidelines based on
> https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP
> >
> >
> >
> > I am finding issues while trying to compile the IPSec plugin code, it is
> exiting with the below error. I have tried with latest VPP master branch,
> the result is pretty much same. Is there any resolution to this issue or am
> I missing something? If I try to use VPP v18.10 branch then I hit other
> netlink issue which I think discussed in this thread in the past. Hence
> moved to latest VPP code base, tried to link VPPSB and build the
> netlink-install and router-install plugins, hitting IPSec build failures.
> Any recommendation would be helpful.
> >
> >
> >
> > I am running Centos 7.4 machine.
> >
> >
> >
> > [root@localhost build-root]# git branch
> >
> > * (detached from v20.01)
> >
> >   master
> >
> >
> >
> > [root@localhost build-root]# *make V=0 PLATFORM=vpp TAG=vpp_debug
> netlink-install router-install*
> >
> >  Arch for platform 'vpp' is native 
> >
> >  Finding source for external 
> >
> >  Makefile fragment found in /root/vpp/build-data/packages/
> external.mk 
> >
> >  Source found in /root/vpp/build 
> >
> >  Arch for platform 'vpp' is native 
> >
> >  Finding source for vpp 
> >
> >  Makefile fragment found in /root/vpp/build-data/packages/vpp.mk
> 
> >
> >  Source found in /root/vpp/src 
> >
> >  Arch for platform 'vpp' is native 
> >
> >  Finding source for netlink 
> >
> >  Makefile fragment found in /root/vpp/build-data/packages/netlink.mk
> 
> >
> >  Source found in /root/vpp/netlink 
> >
> >  Configuring external: nothing to do 
> >
> >  Building external: nothing to do 
> >
> >  Installing external: nothing to do 
> >
> >  Configuring vpp: nothing to do 
> >
> >  Building vpp in /root/vpp/build-root/build-vpp_debug-native/vpp 
> >
> > [1/660] Building C object
> plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o
> >
> > FAILED:
> plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o
> >
> > /opt/rh/devtoolset-7/root/bin/cc -Dcrypto_ipsecmb_plugin_EXPORTS
> -I/root/vpp/src -I. -Iinclude -I/root/vpp/src/plugins -Iplugins
> -I/opt/vpp/external/x86_64/include -Wno-address-of-packed-member -g -fPIC
> -Werror -Wall -march=corei7 -mtune=corei7-avx  -O0 -DCLIB_DEBUG
> -fstack-protector -DFORTIFY_SOURCE=2 -fno-common  -fPIC   -march=silvermont
> -maes -MD -MT
> plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o -MF
> plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o.d
> -o plugins/crypto_ipsecmb/CMakeFiles/crypto_ipsecmb_plugin.dir/ipsecmb.c.o
>   -c /root/vpp/src/plugins/crypto_ipsecmb/ipsecmb.c
> >
> > /root/vpp/src/plugins/crypto_ipsecmb/ipsecmb.c:20:10: fatal error:
> intel-ipsec-mb.h: No such file or directory
> >
> >  #include 
> >
> >   ^~
> >
> > compilation terminated.
> >
> > [4/660] Building C object
> plugins/ct6/CMakeFiles/ct6_test_plugin.dir/ct6_test.c.o
> >
> > ninja: build stopped: subcommand failed.
> >
> > make: *** [vpp-build] Error 1
> >
> > [root@localhost build-root]#
> >
> >
> >
> > Thanks,
> >
> > Kausik
> >
> >
> >
> >
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15551): https://lists.fd.io/g/vpp-dev/message/15551
Mute This Topic: https://lists.fd.io/mt/71543494/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

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/c/vpp/+/22698
[1] https://lists.fd.io/g/vpp-api-dev/message/32
[2] https://lists.fd.io/g/vpp-dev/message/11754

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 Konstantynowicz (mkonstan) 
mailto:mkons...@cisco.com>>
Sent: Wednesday, February 26, 2020 10:09 AM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Cc: csit-...@lists.fd.io; Ed Kern (ejk) 
mailto:e...@cisco.com>>; Dave Wallace (dwallace) 
mailto:dwall...@cisco.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: Gerrit 25463 fails API CRC check for no obvious reason...

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.json files:

13:24:04 {

13:24:04  "ipsec_interface_add_del_spd":"0x80f80cbb",

13:24:04  "ipsec_sad_entry_add_del":"0x57cc13fa",

13:24:04  "ipsec_select_backend":"0x5bcfd3b7",

13:24:04  "ipsec_spd_add_del":"0x20e89a95",

13:24:04  "ipsec_spd_entry_add_del":"0x9f384b8d",

13:24:04  "ipsec_tunnel_if_add_del":"0x2b135e68",

13:24:04  "ipsec_tunnel_if_add_del_reply":"0x5383d31f"

13:24:04 }

13:24:04 RuntimeError('Incompatible API CRCs found in .api.json files:\n{\n 
"ipsec_interface_add_del_spd":"0x80f80cbb",\n 
"ipsec_sad_entry_add_del":"0x57cc13fa",\n 
"ipsec_select_backend":"0x5bcfd3b7",\n "ipsec_spd_add_del":"0x20e89a95",\n 
"ipsec_spd_entry_add_del":"0x9f384b8d",\n 
"ipsec_tunnel_if_add_del":"0x2b135e68",\n 
"ipsec_tunnel_if_add_del_reply":"0x5383d31f"\n}',)


On 26 Feb 2020, at 14:44, Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> 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.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15550): https://lists.fd.io/g/vpp-dev/message/15550
Mute This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Ed Kern via Lists.Fd.Io]

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 from ALL voting jobs.   

This MAY lead to an increase in manual rechecks if we see spike of intermittent 
job failures.   But IMO that should not be a large
percentage increase currently without those connection reset issues.

Please let me know if anyone feels that we should keep the retry mechanic in 
place otherwise ill be putting up a ci-management patch
later today for its removal.

thanks,

Ed






> On Feb 26, 2020, at 8:08 AM, otr...@employees.org wrote:
> 
> 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.
>> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15549): https://lists.fd.io/g/vpp-dev/message/15549
Mute This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

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 Konstantynowicz (mkonstan) 
mailto:mkons...@cisco.com>>
Sent: Wednesday, February 26, 2020 10:09 AM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Cc: csit-...@lists.fd.io; Ed Kern (ejk) 
mailto:e...@cisco.com>>; Dave Wallace (dwallace) 
mailto:dwall...@cisco.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: Gerrit 25463 fails API CRC check for no obvious reason...

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.json files:

13:24:04 {

13:24:04  "ipsec_interface_add_del_spd":"0x80f80cbb",

13:24:04  "ipsec_sad_entry_add_del":"0x57cc13fa",

13:24:04  "ipsec_select_backend":"0x5bcfd3b7",

13:24:04  "ipsec_spd_add_del":"0x20e89a95",

13:24:04  "ipsec_spd_entry_add_del":"0x9f384b8d",

13:24:04  "ipsec_tunnel_if_add_del":"0x2b135e68",

13:24:04  "ipsec_tunnel_if_add_del_reply":"0x5383d31f"

13:24:04 }

13:24:04 RuntimeError('Incompatible API CRCs found in .api.json files:\n{\n 
"ipsec_interface_add_del_spd":"0x80f80cbb",\n 
"ipsec_sad_entry_add_del":"0x57cc13fa",\n 
"ipsec_select_backend":"0x5bcfd3b7",\n "ipsec_spd_add_del":"0x20e89a95",\n 
"ipsec_spd_entry_add_del":"0x9f384b8d",\n 
"ipsec_tunnel_if_add_del":"0x2b135e68",\n 
"ipsec_tunnel_if_add_del_reply":"0x5383d31f"\n}',)


On 26 Feb 2020, at 14:44, Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> 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.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15548): https://lists.fd.io/g/vpp-dev/message/15548
Mute This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Dave Barach via Lists.Fd.Io]

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 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.json files:

13:24:04 {

13:24:04  "ipsec_interface_add_del_spd":"0x80f80cbb",

13:24:04  "ipsec_sad_entry_add_del":"0x57cc13fa",

13:24:04  "ipsec_select_backend":"0x5bcfd3b7",

13:24:04  "ipsec_spd_add_del":"0x20e89a95",

13:24:04  "ipsec_spd_entry_add_del":"0x9f384b8d",

13:24:04  "ipsec_tunnel_if_add_del":"0x2b135e68",

13:24:04  "ipsec_tunnel_if_add_del_reply":"0x5383d31f"

13:24:04 }

13:24:04 RuntimeError('Incompatible API CRCs found in .api.json files:\n{\n 
"ipsec_interface_add_del_spd":"0x80f80cbb",\n 
"ipsec_sad_entry_add_del":"0x57cc13fa",\n 
"ipsec_select_backend":"0x5bcfd3b7",\n "ipsec_spd_add_del":"0x20e89a95",\n 
"ipsec_spd_entry_add_del":"0x9f384b8d",\n 
"ipsec_tunnel_if_add_del":"0x2b135e68",\n 
"ipsec_tunnel_if_add_del_reply":"0x5383d31f"\n}',)



On 26 Feb 2020, at 14:44, Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> 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.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15547): https://lists.fd.io/g/vpp-dev/message/15547
Mute This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Maciek Konstantynowicz (mkonstan) via Lists.Fd.Io]

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.json files:
13:24:04 {
13:24:04  "ipsec_interface_add_del_spd":"0x80f80cbb",
13:24:04  "ipsec_sad_entry_add_del":"0x57cc13fa",
13:24:04  "ipsec_select_backend":"0x5bcfd3b7",
13:24:04  "ipsec_spd_add_del":"0x20e89a95",
13:24:04  "ipsec_spd_entry_add_del":"0x9f384b8d",
13:24:04  "ipsec_tunnel_if_add_del":"0x2b135e68",
13:24:04  "ipsec_tunnel_if_add_del_reply":"0x5383d31f"
13:24:04 }
13:24:04 RuntimeError('Incompatible API CRCs found in .api.json files:\n{\n 
"ipsec_interface_add_del_spd":"0x80f80cbb",\n 
"ipsec_sad_entry_add_del":"0x57cc13fa",\n 
"ipsec_select_backend":"0x5bcfd3b7",\n "ipsec_spd_add_del":"0x20e89a95",\n 
"ipsec_spd_entry_add_del":"0x9f384b8d",\n 
"ipsec_tunnel_if_add_del":"0x2b135e68",\n 
"ipsec_tunnel_if_add_del_reply":"0x5383d31f"\n}',)


On 26 Feb 2020, at 14:44, Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> 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.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15545): https://lists.fd.io/g/vpp-dev/message/15545
Mute This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Ole Troan]

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.
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15546): https://lists.fd.io/g/vpp-dev/message/15546
Mute This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Change interface default MTU to 1500

[Dave Barach via Lists.Fd.Io]

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 Barach (dbarach) ; vpp-dev 
Subject: RE: Change interface default MTU to 1500

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 changing it to 1500.

Regards,
John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Wednesday, February 26, 2020 8:40 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] Change interface default MTU to 1500


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 remembers why we're setting the default MTU 
to 9000.



Thanks... Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15544): https://lists.fd.io/g/vpp-dev/message/15544
Mute This Topic: https://lists.fd.io/mt/71565329/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Change interface default MTU to 1500

[Greg O'Rawe]

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
To: Dave Barach (dbarach) ; vpp-dev 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Change interface default MTU to 1500

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 changing it to 1500.

Regards,
John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Wednesday, February 26, 2020 8:40 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] Change interface default MTU to 1500


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 remembers why we're setting the default MTU 
to 9000.



Thanks... Dave

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15543): https://lists.fd.io/g/vpp-dev/message/15543
Mute This Topic: https://lists.fd.io/mt/71565329/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Change interface default MTU to 1500

[John Lo (loj) via Lists.Fd.Io]

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 changing it to 1500.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Wednesday, February 26, 2020 8:40 AM
To: vpp-dev 
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] Change interface default MTU to 1500


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 remembers why we're setting the default MTU 
to 9000.



Thanks... Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15542): https://lists.fd.io/g/vpp-dev/message/15542
Mute This Topic: https://lists.fd.io/mt/71565329/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Gerrit 25463 fails API CRC check for no obvious reason...

[Dave Barach via Lists.Fd.Io]

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 This Topic: https://lists.fd.io/mt/71566402/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Coverity run FAILED as of 2020-02-26 14:00:24 UTC

[Noreply Jenkins]

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): https://lists.fd.io/g/vpp-dev/message/15540
Mute This Topic: https://lists.fd.io/mt/71565646/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Change interface default MTU to 1500

[Dave Barach via Lists.Fd.Io]

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 remembers why we're setting the default
MTU to 9000.

 

Thanks... Dave 



smime.p7s
Description: S/MIME cryptographic signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15539): https://lists.fd.io/g/vpp-dev/message/15539
Mute This Topic: https://lists.fd.io/mt/71565329/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-