Re: [vpp-dev] Does VPP IPSec support inner fragementation

DBGvpp# set int mtu ? set interface mtuset interface mtu [packet|ip4|ip6|mpls] /neale From: Vijay Kumar Date: Friday, 16 July 2021 at 17:20 To: Neale Ranns Cc: vpp-dev Subject: Re: [vpp-dev] Does VPP IPSec support inner fragementation Hi Neale, Thanks

Re: [vpp-dev] Does VPP IPSec support inner fragementation

Hi Vijay, No, the ESP encrypt code does not account for the egress interface’s MTU. the outer/encapped packet will be fragmented at the phy. But for a route based VPN, where you are protecting a tunnel with an SA, then the encrypt/encap happens after any fragmentation by the tunnel interface.

Re: [vpp-dev] Need help on IPSEC tunnel

Hi Nikhil, Reaching the ip4-not-enabled node means your tunnel is not ip4 enabled. Give it an IP address or make it unnumbered to an interface that has an address. /neale From: vpp-dev@lists.fd.io on behalf of nikhil subhedar via lists.fd.io Date: Tuesday, 13 July 2021 at 18:53 To:

Re: [vpp-dev] ACL IPV6 rule addition using the "set acl_plugin acl" command from "vppctl" #vppctl #acl #acl_plugin #ipv6

rule addition using the "set acl_plugin acl" command from "vppctl" #vppctl #acl #acl_plugin #ipv6 Ravi, appears that the commit 2f8cd914514fe54f91974c6d465d4769dfac8de8 has hardcoded the IP address family in the CLI handler to IPv4: 0490db79b src/plugins/acl/acl.c(Neale

Re: [vpp-dev] MPLS protection

Hi Leela, There’s no FRR. I don’t know what a HA LSP would be. Here’s the docs on what fast convergence support there is: https://github.com/FDio/vpp/blob/master/docs/gettingstarted/developers/fib20/fastconvergence.rst /neale From: vpp-dev@lists.fd.io on behalf of Gudimetla, Leela Sankar

Re: [vpp-dev] having problem pinging gtpu_tunnel0 interface, says Failed: no source address for egress interface

From: Venumadhav Josyula Date: Tuesday, 13 July 2021 at 11:53 To: Neale Ranns Cc: bga...@cisco.com , vpp-dev Subject: Re: [vpp-dev] having problem pinging gtpu_tunnel0 interface, says Failed: no source address for egress interface Hi Neale, Sorry for the late reply, the below patch worked

Re: [vpp-dev] View IPv6 default route

DBGvpp# sh ip6 fib ::/0 ipv6-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[default-route:1, ] ::/0 fib:0 index:5 locks:2 default-route refs:1 entry-flags:drop, src-flags:added,contributing,active, path-list:[7] locks:2 flags:drop,

Re: [vpp-dev] having problem pinging gtpu_tunnel0 interface, says Failed: no source address for egress interface

Try this one: https://gerrit.fd.io/r/c/vpp/+/32801 /neale From: vpp-dev@lists.fd.io on behalf of Benoit Ganne (bganne) via lists.fd.io Date: Thursday, 8 July 2021 at 15:08 To: Venumadhav Josyula Cc: vpp-dev Subject: Re: [vpp-dev] having problem pinging gtpu_tunnel0 interface, says

Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'

Hi Mechthild. From: Mechthild Buescher Date: Monday, 5 July 2021 at 16:25 To: Neale Ranns , Benoit Ganne (bganne) , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' Hi Neale, I tried different configs in several

Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'

From: Mechthild Buescher Date: Thursday, 1 July 2021 at 14:51 To: Neale Ranns , Benoit Ganne (bganne) , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' Hi all, I still don’t have success. This is the configuration I

Re: [vpp-dev] VRRP issue when using interface in a table

details and will come back to you. But thanks for your support so far, BR/Mechthild From: Neale Ranns mailto:ne...@graphiant.com>> Sent: Thursday, 24 June 2021 12:33 To: Mechthild Buescher mailto:mechthild.buesc...@ericsson.com>>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>

Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'

From: Benoit Ganne (bganne) Date: Thursday, 1 July 2021 at 11:35 To: Neale Ranns , Mechthild Buescher , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' >> As 198.19.255.249 is the IP of host-Vpp2Host.409

Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'

From: vpp-dev@lists.fd.io on behalf of Benoit Ganne (bganne) via lists.fd.io Date: Thursday, 1 July 2021 at 10:38 To: Mechthild Buescher , vpp-dev@lists.fd.io Subject: Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' I think the issue is the way

Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'

Hi Mechthild, What Benoit said about punting. You might also find this useful: https://github.com/FDio/vpp/blob/master/src/plugins/linux-cp/FEATURE.yaml plus inline … From: vpp-dev@lists.fd.io on behalf of Mechthild Buescher via lists.fd.io Date: Wednesday, 30 June 2021 at 18:06 To:

Re: [vpp-dev] #vpp-dev : How does the ping works from vppctl when we have 2 entries for the same Dest Addr with different sw_if_index

Hi Sastry, What is the gARP bug and fix you mention? /neale From: vpp-dev@lists.fd.io on behalf of Sastry Sista via lists.fd.io Date: Tuesday, 29 June 2021 at 12:13 To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] #vpp-dev : How does the ping works from vppctl when we have 2 entries for

Re: [vpp-dev] #vpp-dev : How does the ping works from vppctl when we have 2 entries for the same Dest Addr with different sw_if_index

Hi Sastry, As Alex alluded to, the ping code: https://github.com/FDio/vpp/blob/ff2e4138cc020dea4ab0f21f1b172b28f5ed3565/src/plugins/ping/ping.c#L877 uses the FIB to perform the lookup on the destination, it does not consult the neighbour table. The entries in the neighbour table may have

Re: [vpp-dev] VRRP issue when using interface in a table

Hi Mechthild, You’ll need to include: https://gerrit.fd.io/r/c/vpp/+/32298 /neale From: vpp-dev@lists.fd.io on behalf of Mechthild Buescher via lists.fd.io Date: Thursday, 24 June 2021 at 10:49 To: vpp-dev@lists.fd.io Subject: [vpp-dev] VRRP issue when using interface in a table Hi all,

Re: [vpp-dev] MPLS DROP DPO

Hi Mohsen, You programmed the non-EOS entry, but the packet was EOS. MPLS lookup is really a 21 bit lookup; label & EOS-bit. /neale From: vpp-dev@lists.fd.io on behalf of Mohsen Meamarian via lists.fd.io Date: Wednesday, 23 June 2021 at 09:09 To: vpp-dev@lists.fd.io Subject: [vpp-dev]

Re: [vpp-dev] Regarding DPO object

Kumar Date: Thursday, 17 June 2021 at 13:08 To: Neale Ranns Cc: vpp-dev Subject: Re: [vpp-dev] Regarding DPO object Hi Neale, I saw the code of abf_plicy_cmd() function. I was hoping to see something related to DPO in the function unformat_fib_route_path() which parses the ABF CLI. But I did

Re: [vpp-dev] Regarding DPO object

2021 at 16:28 To: Neale Ranns Cc: vpp-dev Subject: Re: [vpp-dev] Regarding DPO object Hi Neale, The ABF is ACL based matching and forwarding plugin right. This would allow one to match a packet with ACL and forward it on a configured outbound interface. My case is different, I don't want

Re: [vpp-dev] Lpm match?

Hi Hemant, Look in fib/ip4_fib.c and fib/ip6_fib.c for the different data-structures that are used. /neale From: vpp-dev@lists.fd.io on behalf of hemant via lists.fd.io Date: Friday, 11 June 2021 at 14:12 To: vpp-dev@lists.fd.io Subject: [vpp-dev] Lpm match? For exact match of a table

Re: [vpp-dev] Regarding DPO object

Hi Vijay, The FIB will only match against a destination prefix. If you want to use DPOs with more complex matching, try the ABF plugin. /neale From: vpp-dev@lists.fd.io on behalf of Vijay Kumar via lists.fd.io Date: Wednesday, 16 June 2021 at 15:04 To: vpp-dev Subject: [vpp-dev] Regarding

Re: [vpp-dev] vpp hangs with bfd configuration

From: vpp-dev@lists.fd.io on behalf of Sudhir CR via lists.fd.io Date: Thursday, 10 June 2021 at 08:50 To: vpp-dev@lists.fd.io Subject: [vpp-dev] vpp hangs with bfd configuration Hi All, when we are trying to establish a BFD session between two containers while processing "adj_bfd_notify ''

Re: [vpp-dev] Regarding IPSec traffic load balancing in VPP

hi Vijay, Yes it does. In the async mode of operation the crypto job part of IPsec can be farmed out to other threads, but the sequence number and anti-reply aspects are always done on the same worker. /neale From: vpp-dev@lists.fd.io on behalf of Vijay Kumar via lists.fd.io Date:

Re: [vpp-dev] Regarding vnet/gre

Hi Vijay, It is called from ipX-midchain. /neale From: Vijay Kumar Date: Tuesday, 25 May 2021 at 17:08 To: Neale Ranns Cc: vpp-dev Subject: Re: [vpp-dev] Regarding vnet/gre Hi Neale, Thanks for the useful input. I will implement a new fixup function similar to the one mentioned. I believe

Re: [vpp-dev] Regarding vnet/gre

Hi Vijay, I’d advise you to create a new fixup function (c.f. gre44_fixup) that deals with the extra headers you want. /neale From: vpp-dev@lists.fd.io on behalf of Vijay Kumar via lists.fd.io Date: Tuesday, 25 May 2021 at 14:07 To: vpp-dev Subject: [vpp-dev] Regarding vnet/gre Hi, I

Re: [vpp-dev] Regarding IPSec sequence number synch

Not that I know of. /neale From: Vijay Kumar Date: Monday, 24 May 2021 at 10:14 To: Neale Ranns Cc: vpp-dev Subject: Re: [vpp-dev] Regarding IPSec sequence number synch Ok, thanks Neale. Is there any plan to develop the IPSec redundancy in future? On Fri, May 21, 2021 at 5:01 PM Neale

Re: [vpp-dev] IPv6 in IPv6 Encapsulation

Right, there’s only so much space available. You’ll need to recompile VPP to get more space. Change the PRE_DATA_SIZE value in src/vlib/CMakeLists.txt. /neale From: jerome.bay...@student.uliege.be Date: Friday, 21 May 2021 at 17:06 To: Neale Ranns Cc: vpp-dev@lists.fd.io , Justin Iurman

Re: [vpp-dev] IPv6 in IPv6 Encapsulation

Does it all start to go wrong when the extension header gets to about 128 bytes? /neale From: jerome.bay...@student.uliege.be Date: Friday, 21 May 2021 at 16:04 To: Neale Ranns Cc: vpp-dev@lists.fd.io , Justin Iurman Subject: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi again Neale, Here

Re: [vpp-dev] IPv6 in IPv6 Encapsulation

Hi Jérôme, A packet trace would help us help you in this case  /neale From: vpp-dev@lists.fd.io on behalf of jerome.bayaux via lists.fd.io Date: Friday, 21 May 2021 at 13:05 To: vpp-dev@lists.fd.io Cc: Justin Iurman Subject: [vpp-dev] IPv6 in IPv6 Encapsulation Hello all, I'm trying to

Re: [vpp-dev] Regarding IPSec sequence number synch

Hi Vijay, It does not. /neale From: vpp-dev@lists.fd.io on behalf of Vijay Kumar via lists.fd.io Date: Thursday, 20 May 2021 at 15:11 To: vpp-dev Subject: [vpp-dev] Regarding IPSec sequence number synch Hi, Does the latest IPSec code support HA. I am interested to know if ESP sequence

Re: [vpp-dev] rewrite constructed using ARPND

Hi Hemant, When I said ‘in the control plane’ in my previous emails, I was referring to within the main thread of VPP, not in a separate user space process. Here the distinction is in the main thread, not in a work thread. When you are populating your 6 tuple lookup table, go find the adj for

Re: [vpp-dev] dst mac-address look up?

From: hem...@mnkcg.com Date: Wednesday, 21 April 2021 at 17:36 To: Neale Ranns , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] dst mac-address look up? Hi Neale, Thanks for your help and patience. The adj is complete, but my data plane doesn’t have an index to find the adj. I get the index

Re: [vpp-dev] dst mac-address look up?

o:hem...@mnkcg.com>>, Neale Ranns mailto:ne...@graphiant.com>>, vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> mailto:vpp-dev@lists.fd.io>> Subject: RE: [vpp-dev] dst mac-address look up? I do see a correct adj in the output from “sh adj” for the pg1 interface. [@16] i

Re: [vpp-dev] dst mac-address look up?

From: hem...@mnkcg.com Date: Monday, 19 April 2021 at 17:23 To: hem...@mnkcg.com , Neale Ranns , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] dst mac-address look up? I do see a correct adj in the output from “sh adj” for the pg1 interface. [@16] ipv6 via 2002::2 pg1: mtu:9000 next:4 flags

Re: [vpp-dev] dst mac-address look up?

From: hem...@mnkcg.com Date: Monday, 19 April 2021 at 16:03 To: Neale Ranns , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] dst mac-address look up? From: Neale Ranns Sent: Monday, April 19, 2021 3:34 AM To: hem...@mnkcg.com; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] dst mac-address look up

Re: [vpp-dev] route based on the source ip

There’s also source VRF select (SVS) plugin /neale From: vpp-dev@lists.fd.io on behalf of Benoit Ganne (bganne) via lists.fd.io Date: Monday, 19 April 2021 at 14:01 To: Venumadhav Josyula , vpp-dev Subject: Re: [vpp-dev] route based on the source ip Hi Venu, You can do that with ABF, see

Re: [vpp-dev] dst mac-address look up?

From: hem...@mnkcg.com Date: Sunday, 18 April 2021 at 19:25 To: Neale Ranns , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] dst mac-address look up? I test using a plugin_test.py script. I am using device-input to ingress packets. The packets undergo a 6-tuple lookup (simplified description

Re: [vpp-dev] dst mac-address look up?

From: hem...@mnkcg.com Date: Sunday, 18 April 2021 at 01:03 To: Neale Ranns , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] dst mac-address look up? From: Neale Ranns Sent: Saturday, April 17, 2021 8:57 AM To: hem...@mnkcg.com; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] dst mac-address look up

Re: [vpp-dev] dst mac-address look up?

From: hem...@mnkcg.com Date: Friday, 16 April 2021 at 21:07 To: Neale Ranns , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] dst mac-address look up? I have not changed any API – it’s only the implementation of an API that has changed. this is the definition of changing the semantics

Re: [vpp-dev] dst mac-address look up?

Please don’t change the semantics of existing APIs. Add a ip_neighbor_find API if you need one. But what is it you are trying to do? Why are you searching the neighbour table and in what context; main or worker thread? /neale From: vpp-dev@lists.fd.io on behalf of hemant via lists.fd.io

Re: [vpp-dev] New Committer Proposal

+1 /neale From: vpp-dev@lists.fd.io on behalf of Damjan Marion via lists.fd.io Date: Wednesday, 31 March 2021 at 19:58 To: vpp-dev Cc: Zhang, Roy Fan Subject: [vpp-dev] New Committer Proposal Dear VPP Committers, I would like to propose Roy Fan Zhang from Intel as a new VPP committer. Fan

Re: [vpp-dev] GRE-over-IPSec fails

Hi Vijay, Are your protecting SAs in transport mode?. see: https://wiki.fd.io/view/VPP/IPSec#Protection_Model /neale From: Vijay Kumar Date: Friday, 26 March 2021 at 02:13 To: Neale Ranns Cc: vpp-dev Subject: Re: [vpp-dev] GRE-over-IPSec fails Hi Neale, Is this issue due to adjacency

Re: [vpp-dev] GRE-over-IPSec fails

, does it work? /neale From: Vijay Kumar Date: Tuesday, 23 March 2021 at 04:18 To: Neale Ranns Cc: vpp-dev Subject: Re: [vpp-dev] GRE-over-IPSec fails Hi Neale, Could you let me know if you faced the mentioned problem anytime? For me only IPSec works fine, Only GRE also works fine. But when I

Re: [vpp-dev] mgre interface get UNRESOLVED fib entry.

From: Vijay Kumar Date: Friday, 19 March 2021 at 21:11 To: vjkumar2003 Cc: Neale Ranns , Vijay Kumar Nagaraj , y...@wangsu.com , vpp-dev@lists.fd.io Subject: Re: [vpp-dev] mgre interface get UNRESOLVED fib entry. Hi Neale, I tested with the correction in fib_index. Verified by gdb

Re: [vpp-dev] mgre interface get UNRESOLVED fib entry.

Hi Vijay, I was able to re-produce your issue. Please try with: https://gerrit.fd.io/r/c/vpp/+/31695 /neale From: Vijay Kumar Nagaraj Date: Friday, 19 March 2021 at 19:12 To: Neale Ranns , Vijay Kumar Cc: y...@wangsu.com , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] mgre interface get

Re: [vpp-dev] mgre interface get UNRESOLVED fib entry.

Hi Vijay, Please ‘sh fib entry 81’ which, according to the adj on the gre tunnel, is the FIB entry to reach the next-hop. /neale From: Vijay Kumar Date: Wednesday, 17 March 2021 at 18:48 To: Neale Ranns Cc: y...@wangsu.com , Vijay Kumar Nagaraj , vpp-dev@lists.fd.io Subject: Re: [vpp-dev

Re: [vpp-dev] mgre interface get UNRESOLVED fib entry.

up route and tried to ping from VPP to the destination host Can you pls share me your mGRE config if it is working? Regards. -- Forwarded message ----- From: Neale Ranns mailto:ne...@graphiant.com>> Date: Mon, Feb 22, 2021 at 8:47 PM Subject: Re: [vpp-dev] mgre interface get UNR

Re: [vpp-dev] Regarding crash in ARP resolution when mGRE is configured

From: Vijay Kumar Date: Monday, 15 March 2021 at 17:12 To: Neale Ranns Cc: vpp-dev Subject: Re: [vpp-dev] Regarding crash in ARP resolution when mGRE is configured Hi Neale, Thank you for the response. I will try to apply the patch shared in the above link. I will let you know the results

Re: [vpp-dev] Regarding crash in ARP resolution when mGRE is configured

Hi Vijay, I don’t know why there is an ‘arp-ipv4’ adjacency on a tunnel interface, that shouldn’t ever happen. I tried to re-create your issue but failed, though I did find some other problems on the way. They are addressed here: https://gerrit.fd.io/r/c/vpp/+/31643 perhaps you could try

Re: [vpp-dev] #vpp #vpp-dev

Hi Nikhil, I suspect the table-d/fib-index is a red herring. From the trace, this is the echo response sent back from VPP: 03:50:52:603867: VirtualFuncEthernet0/6/0-output VirtualFuncEthernet0/6/0.900 IP4: fa:16:3e:78:ca:96 -> fa:16:3e:08:4c:1d 802.1q vlan 900 ICMP: 50.50.50.50 ->

Re: [vpp-dev] Traffic is not put on IPSec tunnel intf ipip0

Have you configured: ipsec tun protect … /neale From: Vijay Kumar Date: Monday, 8 March 2021 at 14:29 To: Neale Ranns , vpp-dev Subject: Re: [vpp-dev] Traffic is not put on IPSec tunnel intf ipip0 Hi Neale, The strongswan (sender) has configured tunnel mode SA. The below is the config

Re: [vpp-dev] Traffic is not put on IPSec tunnel intf ipip0

From: Vijay Kumar Date: Monday, 8 March 2021 at 10:20 To: Neale Ranns Subject: Re: [vpp-dev] Traffic is not put on IPSec tunnel intf ipip0 Hi Neale, The ipip tunnel src points to the VTH IP hosted in VPP while ipip tunnel dst points to an interface hosted in the peer VM (Strongswan). The ESP pkt

Re: [vpp-dev] Traffic is not put on IPSec tunnel intf ipip0

Hi Vijay, VPP drops because the packets don’t classify to your tunnel, not because ESP is not registered. Compare the addresses in the output from ‘sh ipip tun’ with the packet in the trace. /neale From: Vijay Kumar Date: Monday, 8 March 2021 at 09:52 To: Neale Ranns Cc: vpp-dev Subject

Re: [vpp-dev] Traffic is not put on IPSec tunnel intf ipip0

Hi Vijay, ‘unknown IP protocol’ means there is no registered handler for ESP. From the info you gave I am assuming you are using ip-ip tunnel protection with the SAs in transport mode. In that case the incoming packet should classify to the ip-ip tunnel. The fact that it doesn’t, and the fact

Re: [vpp-dev] IPSec proposal to improve "ipsec4-output-feature" node performance

Hi Govind, Flow caches always perform well, but they are more difficult to use than they first appear. Consider asking yourself these questions: 1 – how many entries can the cache contain? 2 – what do you do when the cache is full? How do you age or recycle old flows? 3 – how do you flush the

Re: [vpp-dev] IPSec ESP Tunnel mode config

Hi Govind, Please see: https://wiki.fd.io/view/VPP/IPSec /neale From: Govindarajan Mohandoss Date: Wednesday, 24 February 2021 at 20:34 To: Govindarajan Mohandoss , Neale Ranns , vpp-dev Cc: nd , nd Subject: RE: [vpp-dev] IPSec ESP Tunnel mode config Hi Neale, I was wrong. I did

Re: [vpp-dev] IPSec ESP Tunnel mode config

Dear Govind, The tunnel parameters are parsed separately in recent versions. Try: ipsec sa add 20 spi 1000 esp crypto-alg aes-gcm-128 crypto-key 4a506a794f574265564551694d653768 salt 0x12345678 tunnel src 192.83.1.1 dst 192.83.1.2 /neale From: vpp-dev@lists.fd.io on behalf of Govindarajan

Re: [vpp-dev] Why does ipsec plugin create ipip interface for each IPSec SA installed by ikev2 plugin

From: Vijay Kumar Date: Monday, 22 February 2021 at 16:50 To: Neale Ranns Cc: vpp-dev Subject: Re: [vpp-dev] Why does ipsec plugin create ipip interface for each IPSec SA installed by ikev2 plugin Hi Neale, Please find my comments inline. On Mon, Feb 22, 2021 at 8:41 PM Neale Ranns

Re: [vpp-dev] mgre interface get UNRESOLVED fib entry.

From: vpp-dev@lists.fd.io on behalf of 叶东岗 via lists.fd.io Date: Monday, 22 February 2021 at 13:53 To: vpp-dev@lists.fd.io Subject: [vpp-dev] mgre interface get UNRESOLVED fib entry. Hi: I try to config a mgre interface fellow those steps, then i get an UNRESOLVED fib entry, is it

Re: [vpp-dev] Why does ipsec plugin create ipip interface for each IPSec SA installed by ikev2 plugin

Hi Vijsy, From: vpp-dev@lists.fd.io on behalf of Vijay Kumar via lists.fd.io Date: Monday, 22 February 2021 at 12:59 To: vpp-dev Subject: [vpp-dev] Why does ipsec plugin create ipip interface for each IPSec SA installed by ikev2 plugin Hi, I configured VPP as a responder while Strongswan

Re: [vpp-dev] configuring ip-neighbor via the debug CLI

Hi Ivan, Providing config options via the CLI is not a priority, hence I’s not often done. There’s also no testing for it, so even if it does work once, it may not continue to do so. However, if you wish to contribute such a CLI, then it would be welcome. Regards, Neale From:

Re: [vpp-dev] RFC: Interface Mirroring for Linux Network Stackintegration

. The plugin could then use the VAPI function wrappers over this direct transport. /neale From: Benoit Ganne (bganne) Date: Thursday, 11 February 2021 at 17:17 To: Neale Ranns , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] RFC: Interface Mirroring for Linux Network Stackintegration Hi Neale

Re: [vpp-dev] Fib entries as per show ip fib for prefix has forwarding UNRESOLVED though packet is forwarded.

that adj/path from the ECMP set when the interface goes down, it does not conflict with flushing the ARP cache, which will make the adj incomplete. /neale From: Rupesh Raghuvaran Date: Thursday, 4 February 2021 at 12:58 To: Neale Ranns Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Fib entries

Re: [vpp-dev] Fib entries as per show ip fib for prefix has forwarding UNRESOLVED though packet is forwarded.

What VPP version is this? /neale From: Rupesh Raghuvaran Date: Wednesday, 3 February 2021 at 17:39 To: Neale Ranns Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Fib entries as per show ip fib for prefix has forwarding UNRESOLVED though packet is forwarded. Hi Neale, Looking at the show ip

Re: [vpp-dev] Fib entries as per show ip fib for prefix has forwarding UNRESOLVED though packet is forwarded.

/gettingstarted/developers/fib20/routes.rst#adjacency-source-fib-entries /neale From: Rupesh Raghuvaran Date: Wednesday, 3 February 2021 at 12:03 To: Neale Ranns Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Fib entries as per show ip fib for prefix has forwarding UNRESOLVED though packet is forwarded

Re: [vpp-dev] Fib entries as per show ip fib for prefix has forwarding UNRESOLVED though packet is forwarded.

Hi Rupesh, 10.0.0.15 remains unresolved after link down because there remains an adjacency/ARP-entry for it on Ge0/4/0 – did you add a static one? It is unresolved because it fails the adjacency source refinement criteria. Packets to 10.0.0.15 are forwarded using the default route. This is

[vpp-dev] RFC: Interface Mirroring for Linux Network Stackintegration

Dear All, I’d like to solicit comments for this proposed patch: https://gerrit.fd.io/r/c/vpp/+/30759 this is a scheme that aids with the integration of VPP with the Linux network stack by mirroring a [user defined] set of interfaces that VPP owns with tap/tun interfaces in the kernel. More

Re: [vpp-dev] local lookup and tx sw_if_index

Hi Stanislav, There is no TX interface information if the packet is for-us. There is only valid TX interface information if the routing decision was to TX on an interface. How do you choose the egress Tap? /neale From: vpp-dev@lists.fd.io on behalf of Stanislav Zaikin via lists.fd.io

Re: [vpp-dev] classifier howto?

Hi Hemant, I’ll be a little more direct  you can’t expand the size of opaque. The blast radius of such a change is just too large. Your alternative choices are: 1) use oqaque2, 2) overlay your ‘value’ field in the union in opaque. The latter is preferable since you won’t incur the cost of

Re: [vpp-dev] GRE Tunnel IP6 over IP6

Hi Vikram, Thanks for the trace. I was able to create a UT case for this. It is an issue in VPP when parsing the destination option header. I will work on it. /neale From: Vikram Sachdeva Date: Monday, 18 January 2021 at 10:26 To: Neale Ranns Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev

Re: [vpp-dev] GRE Tunnel IP6 over IP6

Hi Vikram, I don’t see a v6 tunnel encapped packet in that trace. /neale From: Vikram Sachdeva Date: Monday, 18 January 2021 at 09:11 To: Neale Ranns Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] GRE Tunnel IP6 over IP6 Hi Neale, Please find the pcap attached. I have created two tunnels

Re: [vpp-dev] VPP New Plugin-Packet Forwarding

Hi, In addition to defining what the next-node is, you need to be sure that your node sets all the necessary buffer meta data that the next node will use. For example interface-output expects that vnet_buffer(b)->sw_if_index[VLIB_TX] is set to the interface to transmit on. /neale From:

Re: [vpp-dev] GRE Tunnel IP6 over IP6

Hi, It’s not clear [to me at least] why the packet in your trace was dropped. It was an IPv6 packet to/from the tunnel src/dst, but it has IPv6 extension header for ‘destination options’. VPP was not able to read past this header for reasons I cannot say from that trace alone. I would suggest

Re: [vpp-dev] move to clang-format

+1. /neale From: on behalf of Florin Coras Date: Wednesday 16 December 2020 at 16:14 To: Damjan Marion Cc: vpp-dev Subject: Re: [vpp-dev] move to clang-format +1 Florin On Dec 16, 2020, at 6:12 AM, Damjan Marion via lists.fd.io mailto:dmarion=me@lists.fd.io>>

Re: [vpp-dev] VPP ip route add multiple paths

Hello Anonymous, In order to debug IP forwarding issues I’m going to need more info. Please collect: ‘sh ip fib ’ From a working and non-working configuration. All FIB load-balancing is per-flow. So if you don’t have enough flows you won’t [necessarily] get the load distribution that you

Re: [vpp-dev] replacing make test-checkstyle with black

Hi Paul, Having to write code to conform to python linting is my number 1 annoyance when writing tests. This is my usual hack: e = VppEnum.vl_api_tunnel_encap_decap_flags_t f = e.TUNNEL_API_ENCAP_DECAP_FLAG_ENCAP_COPY_DSCP I support having an auto-linter. I have no knowledge about what’s

Re: [vpp-dev] why tunnel interfaces do not support device-input feature?

Hi Ye, Some comments inline... On 17/11/2020 02:34, "vpp-dev@lists.fd.io on behalf of 叶东岗" wrote: Hi all: why tunnel interfaces do not support device-input feature? No one has asked for/contributed such support. If you're volunteering, here's some advice. Taking the feature arc

Re: [vpp-dev] Facing issue in IPSEC data traffic after SA is setup successfully

Hi Vijay, From: vpp-dev@lists.fd.io Date: Thursday, 5 November 2020 at 16:54 To: vpp-dev@lists.fd.io Subject: [vpp-dev] Facing issue in IPSEC data traffic after SA is setup successfully Hi, I have set up IPSEC SA successfully b/w the Strongswan (initiator) and the VPP IPSec (responder).

Re: [vpp-dev] [vpp-committers] VPP committers: VPP PTL vote

+1. If I had more pluses to give, I would. /neale From: on behalf of "Dave Barach via lists.fd.io" Reply to: "Dave Barach (dbarach)" Date: Friday 25 September 2020 at 21:14 To: "vpp-committ...@lists.fd.io" Cc: "vpp-dev@lists.fd.io" Subject: [vpp-committers] VPP committers: VPP PTL vote

Re: [vpp-dev] The gratuitous ARP issue

Hi Jinlei, Thank you for the info. I have updated the UT to reflect this and the problem was seen. I have fixed the issue and updated the patch. /neale From: Jerry Li Date: Wednesday 23 September 2020 at 17:42 To: "Neale Ranns (nranns)" Cc: "vpp-dev@lists.fd.io" Subj

Re: [vpp-dev] The gratuitous ARP issue

at 04:02 To: "Neale Ranns (nranns)" Cc: "vpp-dev@lists.fd.io" Subject: Re:Re: [vpp-dev] The gratuitous ARP issue Hi neale, Thanks for your reply. Attached the pcaps file for my test. I tried to set the Opcode of arp packet as request(1) or reply(2), both the same occurs on

Re: [vpp-dev] The gratuitous ARP issue

Hi Jinlei, Could you please send me a pcap capture of the grat-arp that VPP receives. Then I can duplicate the case in the UT. Thanks, neale From: on behalf of Jinlei Li Date: Saturday 19 September 2020 at 11:56 To: "vpp-dev@lists.fd.io" Subject: [vpp-dev] The gratuitous ARP issue Hi guys,

Re: [vpp-dev] ARP resolution from non-connected IP

Hi Murty, ARP works the same way even when using MH-BGP :) Your peer is not directly connected, therefore you ARP for the nexthop, that's the target address. The source address comes from the interface on which the nexthop is attached, I.e the one on which the ARP is sent. this is not the

Re: [vpp-dev] ARP resolution from non-connected IP

. /neale On 20/08/2020 09:01, "Benoit Ganne (bganne)" wrote: Maybe a workaround would be to add the host prefix of the router loopback in the fib? Eg. 'ip route add /32 '? Best ben > -Original Message- > From: vpp-dev@lists.fd.io On Behal

Re: [vpp-dev] ARP resolution from non-connected IP

There's no way to disable the check. VPP expects the ARP request to have only address that belong to the link on which the ARP packet is sent. IMHO the sender's behaviour is wrong. /neale tpyed by my fat tumhbs From: vpp-dev@lists.fd.io on behalf of Satya

Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif

You can't use the same address as a nexthop in a route and as an address applied to one of your own interfaces: you can't route to yourself. You might also want to read: https://fd.io/docs/vpp/master/gettingstarted/developers/fib20/attachedexport.html /neale tpyed by my fat tumhbs

Re: [vpp-dev] ABF and ACL co-existence on an Interface

, to forwarding. /neale tpyed by my fat tumhbs From: Balaji Venkatraman (balajiv) Sent: Wednesday, August 12, 2020 5:08:51 PM To: Neale Ranns (nranns) Cc: vpp-dev@lists.fd.io ; Venkat ; Andrew  Yourtchenko Subject: Re: [vpp-dev] ABF and ACL co-existence on an Interface

Re: [vpp-dev] ABF and ACL co-existence on an Interface

IMO it's reasonable to use ACL and ABF on the same interface as they provide independent functions, especially when they are matching against different criteria. Re the debug CLI, it's often not robust to garbage input. If the API has the same problem though, I'll fix it. Neale tpyed by my

Re: [vpp-dev] VPP 2005 crash with ip6 link local packets #vpp

(and the same for ip4). /neale tpyed by my fat tumhbs From: Vipul Agrawal Sent: Tuesday, July 28, 2020 11:04:32 AM To: Neale Ranns (nranns) ; vpp-dev@lists.fd.io Subject: RE: [vpp-dev] VPP 2005 crash with ip6 link local packets #vpp Please find attached packet

Re: [vpp-dev] VPP 2005 crash with ip6 link local packets #vpp

Please give me a packet trace of an ip6 packet that tpyed by my fat tumhbs From: vpp-dev@lists.fd.io on behalf of vipul.agra...@enea.com Sent: Monday, July 27, 2020 6:26:39 AM To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] VPP 2005 crash with ip6 link local

Re: [vpp-dev] Regarding new ipsec interface patch

; vpp-dev Cc: Neale Ranns (nranns) Subject: RE: [vpp-dev] Regarding new ipsec interface patch We can merge the patch as soon as Neale removes his -2 from it... D. -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Christian Hopps Sent: Monday, July 20, 2020 7:50 AM To: vpp-dev Cc

Re: [vpp-dev] Observing a crash in vpp-20.05

is not ip6 enabled it should have been dropped earlier. /neale tpyed by my fat tumhbs From: Dave Barach (dbarach) Sent: Monday, July 6, 2020 2:01:49 PM To: Amit Mehra ; vpp-dev@lists.fd.io ; Neale Ranns (nranns) Subject: RE: [vpp-dev] Observing a crash in vpp-20.05

Re: [vpp-dev] ipsec interface revisted.

From: Christian Hopps Date: Friday 26 June 2020 at 12:13 To: "Neale Ranns (nranns)" Cc: Christian Hopps , vpp-dev Subject: Re: [vpp-dev] ipsec interface revisted. On Jun 26, 2020, at 4:22 AM, Neale Ranns (nranns) mailto:nra...@cisco.com>> wrote: Hi Chris, As far as I'm

Re: [vpp-dev] ipsec interface revisted.

Hi Chris, As far as I'm concerned, it's your plugin, you can add whatever functionality you need. If you separate the new interface type out into another plugin, so it can be used without your feature, then the community will benefit twice. Let's just make sure we document the whys and hows

Re: [vpp-dev] ipsec interface revisted.

Hi Chris, On 22/06/2020 13:09, "Christian Hopps" wrote: > > - It operates directly with the IPsec tunnel mode and transport mode SAs without needing to mangle the internal definition of SA tunnel into transport mode. Do you have any comments on this point? This is what I was

Re: [vpp-dev] VPP API CRC compatibility check process in checkstyle merged and active

From: on behalf of Andrew Yourtchenko Date: Thursday 18 June 2020 at 17:58 To: "Neale Ranns (nranns)" Cc: vpp-dev Subject: Re: [vpp-dev] VPP API CRC compatibility check process in checkstyle merged and active Hi Neale, On 18 Jun 2020, at 17:11, Neale Ranns (nranns) wrote:

Re: [vpp-dev] ipsec interface revisted.

From: on behalf of Christian Hopps Date: Thursday 18 June 2020 at 18:20 To: vpp-dev Cc: Christian Hopps Subject: [vpp-dev] ipsec interface revisted. Hi, So to revisit this topic from a different angle. I believe VPP needs something like the xfrm linux interface [1]. If I understand things

Re: [vpp-dev] VPP API CRC compatibility check process in checkstyle merged and active

Hi Andrew, A couple of questions? Firstly, about unit testing aka make test. This is the salient passage in your guide: "foo_message_v2 is tested in "make test" to the same extent as the foo_message" IMHO "to the same extent" implies everywhere v1 is used v2 should now be used in its place.

Re: [vpp-dev] ACL plugin optimization

Hi Govind, As well as removing the prefetches, you've also removed the per packet call to acl_fa_find_session_with_hash(). So IIUC you've removed the per-packet session lookup and instead re-use the lookup of packet 0 each time. that'll make things quicker but it's not functionally correct.

<    1   2   3   4   5   6   7   >