Re: [vpp-dev] How to match a specific packet to the outbound direction of a specified interface #vpp
Another solution is to redirect the traffic from punt node to your feature node. Here you can match on packets of interest and send them to interfere output node. Thanks, Rajith On Sat 9 May, 2020, 3:43 PM Mrityunjay Kumar, wrote: > which vpp version are you heading? If you r using 19.05 or less, you can > create ipsec tunnel, and route your packet to ipsec0 interface, > > create ipsec tunnel local-ip local-spi remote-ip > remote-spi > set interface ipsec key ipsec0 local crypto aes-gcm-128 > 2b7e151628aed2a6abf7158809cf4f3d > set interface ipsec key ipsec0 remote crypto aes-gcm-128 > 2b7e151628aed2a6abf7158809cf4f3d > set interface state ipsec0 up > set interface unnumbered ipsec0 use > ip route add 192.168.200.10/24 via ipsec0 > > if your are using >= 19.08, best practice, you can create policy based > tunnel. > > ipsec policy add spd 1 priority 100 inbound action bypass protocol 50 > ipsec policy add spd 1 priority 100 outbound action bypass protocol 50 > ipsec policy add spd 1 outbound action bypass local-ip-range > 10.168.4.0-10.168.4.255 remote-ip-range 10.168.2.0-10.168.2.255 > ipsec sa add 10 spi 3391172682 esp crypto-alg aes-gcm-256 crypto-key > 523a88fa4ad8c0325d75c933d9e567c23879ea701355207551bc2cf7d963c3dac8dcdca2 > tunnel-src 10.168.2.4 tunnel-dst 10.168.4.11 > ipsec sa add 20 spi 3443809241 esp crypto-alg aes-gcm-256 crypto-key > 6062e3e9a9d578f58527242e9fbd48aeef7a0f8b4adc4569e7a84cda19c14ae21aa0a2b4 > tunnel-src 10.168.4.11 tunnel-dst 10.168.2.4 > ipsec policy add spd 1 priority 10 inbound action protect sa 10 > local-ip-range 10.168.3.11 - 10.168.3.11 remote-ip-range 10.168.2.4 - > 10.168.2.4 > ipsec policy add spd 1 priority 10 outbound action protect sa 20 > local-ip-range 10.168.3.11 - 10.168.3.11 remote-ip-range 10.168.2.4 - > 10.168.2.4 > > > > cheers! enjoy > //MJ > > > > *Regards*, > Mrityunjay Kumar. > Mobile: +91 - 9731528504 > > > > On Sat, May 9, 2020 at 12:16 PM wrote: > >> Hi VPP hackers, >> My program and vpp communicate through the memif interface. >> I want to make vpp match specific packets（such as ospf packet）, and then >> redirect to the outbound direction of the memif interface. >> >> I don't know how to match a specific packet to the outbound direction of >> a specified interface. >> >> Can someone provide an example of configuration. >> Thanks in advance！ >> >> > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16294): https://lists.fd.io/g/vpp-dev/message/16294 Mute This Topic: https://lists.fd.io/mt/74091305/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&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] Chelsio CXGBE crash on startup #dpdk
I am facing crash issue on startup running Chelsio T6 NIC (cxgb pmd)
Also tested with v19.08.2 and v18.10
OS:
CentOS 7
Config:
unix { interactive } dpdk { dev :18:00.4 }
Backtrace:
#0 0x7f87a15f0387 in raise () from /lib64/libc.so.6
#1 0x7f87a15f1a78 in abort () from /lib64/libc.so.6
#2 0x0040748d in os_exit (code=1) at
/opt/vpp-src/vpp/src/vpp/vnet/main.c:379
#3 0x7f87a2f9b492 in unix_signal_handler (signum=11, si=0x7f8760e39ef0,
uc=0x7f8760e39dc0) at /opt/vpp-src/vpp/src/vlib/unix/main.c:187
#4
#5 0x7f875e36d453 in cxgbe_poll () from
/opt/vpp-src/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins/dpdk_plugin.so
#6 0x7f875e35a3e0 in cxgbe_dev_link_update () from
/opt/vpp-src/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins/dpdk_plugin.so
#7 0x7f875e29933d in rte_eth_link_get_nowait () from
/opt/vpp-src/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins/dpdk_plugin.so
#8 0x7f875f675fd4 in dpdk_lib_init (dm=0x7f875fed7000 ) at
/opt/vpp-src/vpp/src/plugins/dpdk/device/init.c:281
#9 0x7f875f67df5e in dpdk_process (vm=0x7f87a31d4640 ,
rt=0x7f8760e1a000, f=0x0) at
/opt/vpp-src/vpp/src/plugins/dpdk/device/init.c:1632
#10 0x7f87a2f341f4 in vlib_process_bootstrap (_a=140219410963408) at
/opt/vpp-src/vpp/src/vlib/main.c:1475
#11 0x7f87a23b1ee4 in clib_calljmp () at
/opt/vpp-src/vpp/src/vppinfra/longjmp.S:123
#12 0x7f87602e5ba0 in ?? ()
#13 0x7f87a2f342fc in vlib_process_startup (vm=0x7f87a31d4640
, p=0x7f8760e1a000, f=0x0) at
/opt/vpp-src/vpp/src/vlib/main.c:1497
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16295): https://lists.fd.io/g/vpp-dev/message/16295
Mute This Topic: https://lists.fd.io/mt/74113417/21656
Mute #dpdk: https://lists.fd.io/mk?hashtag=dpdk&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] Chelsio CXGBE crash on startup #dpdk
Hi Mohammed
I guess, If you are lucky, then below patch will work for you. Hope
your firmware version >= 1.17.14.0.
diff --git a/build/external/packages/dpdk.mk b/build/external/packages/
dpdk.mk
index a068210..49fcc5a 100644
--- a/build/external/packages/dpdk.mk
+++ b/build/external/packages/dpdk.mk
@@ -200,6 +200,7 @@ $(B)/custom-config: $(B)/.dpdk-patch.ok Makefile
$(call set,RTE_LIBRTE_PMD_TAP,$(DPDK_TAP_PMD))
$(call set,RTE_LIBRTE_GSO,$(DPDK_TAP_PMD))
$(call set,RTE_LIBRTE_PMD_FAILSAFE,$(DPDK_FAILSAFE_PMD))
*+ $(call set,RTE_LIBRTE_CXGBE_PMD,y)*
@# not needed
$(call set,RTE_ETHDEV_RXTX_CALLBACKS,n)
$(call set,RTE_LIBRTE_CFGFILE,n)
*Regards*,
Mrityunjay Kumar.
Mobile: +91 - 9731528504
On Sun, May 10, 2020 at 4:48 PM Mohammed Alshohayeb
wrote:
> I am facing crash issue on startup running Chelsio T6 NIC (cxgb pmd)
>
> Also tested with v19.08.2 and v18.10
>
> OS:
> CentOS 7
>
> Config:
> unix { interactive } dpdk { dev :18:00.4 }
>
> Backtrace:
> #0 0x7f87a15f0387 in raise () from /lib64/libc.so.6
> #1 0x7f87a15f1a78 in abort () from /lib64/libc.so.6
> #2 0x0040748d in os_exit (code=1) at
> /opt/vpp-src/vpp/src/vpp/vnet/main.c:379
> #3 0x7f87a2f9b492 in unix_signal_handler (signum=11,
> si=0x7f8760e39ef0, uc=0x7f8760e39dc0) at
> /opt/vpp-src/vpp/src/vlib/unix/main.c:187
> #4
> #5 0x7f875e36d453 in cxgbe_poll () from
> /opt/vpp-src/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins/dpdk_plugin.so
> #6 0x7f875e35a3e0 in cxgbe_dev_link_update () from
> /opt/vpp-src/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins/dpdk_plugin.so
> #7 0x7f875e29933d in rte_eth_link_get_nowait () from
> /opt/vpp-src/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins/dpdk_plugin.so
> #8 0x7f875f675fd4 in dpdk_lib_init (dm=0x7f875fed7000 ) at
> /opt/vpp-src/vpp/src/plugins/dpdk/device/init.c:281
> #9 0x7f875f67df5e in dpdk_process (vm=0x7f87a31d4640
> , rt=0x7f8760e1a000, f=0x0) at
> /opt/vpp-src/vpp/src/plugins/dpdk/device/init.c:1632
> #10 0x7f87a2f341f4 in vlib_process_bootstrap (_a=140219410963408) at
> /opt/vpp-src/vpp/src/vlib/main.c:1475
> #11 0x7f87a23b1ee4 in clib_calljmp () at
> /opt/vpp-src/vpp/src/vppinfra/longjmp.S:123
> #12 0x7f87602e5ba0 in ?? ()
> #13 0x7f87a2f342fc in vlib_process_startup (vm=0x7f87a31d4640
> , p=0x7f8760e1a000, f=0x0) at
> /opt/vpp-src/vpp/src/vlib/main.c:1497
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16296): https://lists.fd.io/g/vpp-dev/message/16296
Mute This Topic: https://lists.fd.io/mt/74113417/21656
Mute #dpdk: https://lists.fd.io/mk?hashtag=dpdk&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] IPsec tunnel interfaces?
> On May 9, 2020, at 7:23 AM, Neale Ranns via lists.fd.io
> wrote:
>
>
>
> Hi Chris,
>
>
> > Are there other properties of a tunnel mode SA that you need that are lost
> > with this approach?
>
> I need to use tunnel mode SAs provided by IKEv2. Transport mode is an
> optional (normally on-the-wire IKEv2 negotiated) feature of IPsec. These
> tunnel mode SAs will have IPTFS enabled on them, and that functionality is
> only defined for IPsec tunnel mode SAs.
>
>
> The only difference in VPP between a transport and tunnel mode SA is the
> presence of the encap. So I think it’s fair to say that what you need is an
> interface to interact with the L[23] system, ‘encap’ to describe how to
> encap/decap packets (i.e. what to copy from overlay/underlay (DSCP, ECN, etc)
> and an SA (for the algo set);
>
> Interface + encap + SA
>
> VPP doesn’t model encap separately. So it’s a question of where you add the
> parenthesis.
>
> (interface + encap) + SA = ipip tunnel + transport mode SA
>
> Or
>
> Interface + (encap + SA) = ipsec dedicated interface + tunnel mode SA
>
> In both cases the same information is available, it’s just modelled
> differently. The first model is used since it reuses the types/functionality
> that VPP already has to support other use case, without the need for a
> dedicated interface type. Is it not possible for you to work with the first
> model, or is it less convenient?
SO, I have implemented https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01
in VPP 19.08. The functionality is working as specified in the draft using
tunnel mode SAs.
Conceptually what happens (commonly) is this:
Pkt Pkt Single IPsec
Tunnel Pkt
--- ---
--
[UA]..[Un] ---> user-intf [ VPP ] sa-tunnel-intf ---> [IP(SATunnel) + ESP +
[UA]..[Un][Pad]]
The encpasulation *has* to occur at the SA tunnel point, not pre-encapsulated
by a generic IP-IP interface with a transport mode SA attached to it downstream.
The key here is that there is not a 1-1 mapping of user IP packets to IPsec
packets. FWIW, this isn't just a problem for this particular IPTFS technology,
there are other simple cases (e.g., sending only pad IPsec packets for limited
traffic flow confidentiality) where there is not a 1-1 mapping between user IP
packets and SA tunnel mode packets.
Now, re-architecting IPTFS to exist outside of IPsec so that it could be a new
generic IP tunnel technology is certainly a fun idea (topic for another
thread), it's just not an option, or relevant to the functionality that appears
to have been lost in VPP.
Here's a packet trace for how this works (incoming ping):
USER-SIDE:
00:00:08:845351: dpdk-input
...
ICMP echo_request checksum 0xaea9
00:00:08:845366: ethernet-input
00:00:08:845382: ip4-input-no-checksum
ICMP: 11.11.11.253 -> 12.12.12.12
ICMP echo_request checksum 0xaea9
00:00:08:845389: ip4-lookup
ICMP: 11.11.11.253 -> 12.12.12.12
ICMP echo_request checksum 0xaea9
00:00:08:845396: ip4-midchain
ICMP: 11.11.11.253 -> 12.12.12.12
ICMP echo_request checksum 0xaea9
00:00:08:845402: iptfs-encap4-tun
sa_index: 1
AGGREGATING AND QUEUEING OCCURS - The packet is encapsulated (along with any
others currently waiting) into the next-to-be-sent IPTFS packet, which is
queued to be sent on a timer from another thread, that output thread follows:
SEUCRE-SIDE:
Packet 1
This is the next IPTFS packet to send (in this case it just has the 1 ping
packet inside but usually has multiple when there's real traffic):
00:00:08:851581: handoff_trace
HANDED-OFF: from thread 1 trace index 0
00:00:08:851581: iptfs-output
IPTFS Basic Header: flags: 0 resv 0 offset 0:[output gen: 526 pkt 0 of 1]:
datablock 0: type: IPv4 offset:4 pktlen: 84
datablock 1: type: Pad offset: 88 pktlen: 1382
00:00:08:851622: dpdk-esp4-encrypt
spi 1112 seq 1 seq_hi 0 iv_size 0 trunc_size 0
pad_bytes 0 next_header 143
cipher none auth none
IPTFS Basic Header: flags: 0 resv 0 offset 0
This is the output from the DPDK encryption offload (same packet as above but
encrypted)
Packet 2
00:00:08:851659: dpdk-crypto-input
cryptodev-id 0 next-index 1
00:00:08:851663: ip4-lookup
fib 0 dpo-idx 3 flow hash: 0x
IPSEC_ESP: 13.13.13.11 -> 13.13.13.12
00:00:08:851671: ip4-rewrite
00:00:08:851676: TenGigabitEthernet65/0/1-output
TenGigabitEthernet65/0/1
IP4: f8:f2:1e:3c:08:29 -> f8:f2:1e:3c:09:b1
IPSEC_ESP: 13.13.13.11 -> 13.13.13.12
00:00:08:851682: TenGigabitEthernet65/0/1-tx
TenGigabitEthernet65/0/1 tx queue 5
buffer 0x3feb11e: current data -32, length 1514, buffer-pool 0, ref-count 1,
totlen-nifb 0, trace handle 0x501
To arrive at this setup the code I add myself as a feature.
VNET_FEATURE_INIT (iptfs_encap4_tun_feat_node, static) = {
.arc_name = "ip4-output",
.node_name =
Re: [vpp-dev] IPsec tunnel interfaces?
Just a general followup in case tl;dr The point of traffic flow security/confidentiality is to hide the effects of the user traffic on the secure tunnel output. With IPTFS there is a complete decoupling so that one cannot infer anything about the encapsulated traffic from the IPsec tunnel data packets (when they are sent, how big they are, etc), there are other (more complex) methods for obfuscation that may or may not be better. In any case, having the user data traffic directly determine the IPsec tunnel behavior is inherently less secure than if it doesn't, so the idea that one could find an equivalence between a tunnel mode SA and a transport mode SA doesn't work here. For some uses of IPsec it may work, but not always. In order to make transport mode work (e.g., to support the Cisco-preferred, thus common, GRE+transport IPsec config) we are going to have to do more standards work and probably put various limitations etc on the types of user IP that can be input (so that we can cache and replicate that information at will) -- but that does not represent an equivalence. Thanks, Chris. > On May 10, 2020, at 8:33 AM, Christian Hopps wrote: > >> On May 9, 2020, at 7:23 AM, Neale Ranns via lists.fd.io >> wrote: >> >> >> >> Hi Chris, >> >> >>> Are there other properties of a tunnel mode SA that you need that are lost >>> with this approach? >> >> I need to use tunnel mode SAs provided by IKEv2. Transport mode is an >> optional (normally on-the-wire IKEv2 negotiated) feature of IPsec. These >> tunnel mode SAs will have IPTFS enabled on them, and that functionality is >> only defined for IPsec tunnel mode SAs. >> >> >> The only difference in VPP between a transport and tunnel mode SA is the >> presence of the encap. So I think it’s fair to say that what you need is an >> interface to interact with the L[23] system, ‘encap’ to describe how to >> encap/decap packets (i.e. what to copy from overlay/underlay (DSCP, ECN, >> etc) and an SA (for the algo set); >> >> Interface + encap + SA >> >> VPP doesn’t model encap separately. So it’s a question of where you add the >> parenthesis. >> >> (interface + encap) + SA = ipip tunnel + transport mode SA >> >> Or >> >> Interface + (encap + SA) = ipsec dedicated interface + tunnel mode SA >> >> In both cases the same information is available, it’s just modelled >> differently. The first model is used since it reuses the types/functionality >> that VPP already has to support other use case, without the need for a >> dedicated interface type. Is it not possible for you to work with the first >> model, or is it less convenient? > > SO, I have implemented > https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 in VPP 19.08. The > functionality is working as specified in the draft using tunnel mode SAs. > > Conceptually what happens (commonly) is this: > > > Pkt Pkt Single IPsec > Tunnel Pkt > --- --- > -- > [UA]..[Un] ---> user-intf [ VPP ] sa-tunnel-intf ---> [IP(SATunnel) + ESP + > [UA]..[Un][Pad]] > > > The encpasulation *has* to occur at the SA tunnel point, not pre-encapsulated > by a generic IP-IP interface with a transport mode SA attached to it > downstream. > > The key here is that there is not a 1-1 mapping of user IP packets to IPsec > packets. FWIW, this isn't just a problem for this particular IPTFS > technology, there are other simple cases (e.g., sending only pad IPsec > packets for limited traffic flow confidentiality) where there is not a 1-1 > mapping between user IP packets and SA tunnel mode packets. > > Now, re-architecting IPTFS to exist outside of IPsec so that it could be a > new generic IP tunnel technology is certainly a fun idea (topic for another > thread), it's just not an option, or relevant to the functionality that > appears to have been lost in VPP. > > Here's a packet trace for how this works (incoming ping): > > USER-SIDE: > > 00:00:08:845351: dpdk-input > ... > ICMP echo_request checksum 0xaea9 > 00:00:08:845366: ethernet-input > 00:00:08:845382: ip4-input-no-checksum > ICMP: 11.11.11.253 -> 12.12.12.12 > ICMP echo_request checksum 0xaea9 > 00:00:08:845389: ip4-lookup > ICMP: 11.11.11.253 -> 12.12.12.12 > ICMP echo_request checksum 0xaea9 > 00:00:08:845396: ip4-midchain >ICMP: 11.11.11.253 -> 12.12.12.12 >ICMP echo_request checksum 0xaea9 > 00:00:08:845402: iptfs-encap4-tun > sa_index: 1 > > > AGGREGATING AND QUEUEING OCCURS - The packet is encapsulated (along with any > others currently waiting) into the next-to-be-sent IPTFS packet, which is > queued to be sent on a timer from another thread, that output thread follows: > > > SEUCRE-SIDE: > > Packet 1 > > This is the next IPTFS packet to send (in this case it just has the 1 ping > packet inside but usually has multiple when there's real traffic): > > 00:0
Re: [vpp-dev] Chelsio CXGBE crash on startup #dpdk
Thanks Mrityunjay, CXGBE_PMD is enabled by default in VPP dpdk build, the PMD is built and the interfaces are detected, however, as you can see from the backtrace is dies when trying to link_update? (I assume) Best, Mohammed -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16299): https://lists.fd.io/g/vpp-dev/message/16299 Mute This Topic: https://lists.fd.io/mt/74113417/21656 Mute #dpdk: https://lists.fd.io/mk?hashtag=dpdk&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
