Hi,
Below is the trace output for "unknown ip protocol" related drops for the
ESP pkts coming from the strongswan to VPP.
Let me know If I need to add some ip4-punt related config.
show trace o/p
===============
00:08:29:451365: dpdk-input
VirtualFuncEthernet0/7/0 rx queue 0
buffer 0x4c2d69: current data 0, length 170, buffer-pool 0, ref-count 1,
totlen-nifb 0, trace handle 0x1000001
ext-hdr-valid
l4-cksum-computed l4-cksum-correct
PKT MBUF: port 0, nb_segs 1, pkt_len 170
buf_len 2176, data_len 170, ol_flags 0x180, data_off 128, phys_addr
0x4ecb5ac0
packet_type 0x691 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
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_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without
extension headers
RTE_PTYPE_L4_NONFRAG (0x0600) Non-fragmented IP packet
IP4: fa:16:3e:4b:6b:42 -> fa:16:3e:c2:b4:f4 802.1q vlan 1556
IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
tos 0x00, ttl 64, length 152, checksum 0xbe54 dscp CS0 ecn NON_ECN
fragment id 0x8c7d, flags DONT_FRAGMENT
00:08:29:451372: ethernet-input
frame: flags 0x3, hw-if-index 3, sw-if-index 3
IP4: fa:16:3e:4b:6b:42 -> fa:16:3e:c2:b4:f4 802.1q vlan 1556
00:08:29:451377: ip4-input
IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
tos 0x00, ttl 64, length 152, checksum 0xbe54 dscp CS0 ecn NON_ECN
fragment id 0x8c7d, flags DONT_FRAGMENT
00:08:29:451380: ip4-lookup
fib 1 dpo-idx 27 flow hash: 0x00000000
IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
tos 0x00, ttl 64, length 152, checksum 0xbe54 dscp CS0 ecn NON_ECN
fragment id 0x8c7d, flags DONT_FRAGMENT
00:08:29:451382: ip4-local
IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
tos 0x00, ttl 64, length 152, checksum 0xbe54 dscp CS0 ecn NON_ECN
fragment id 0x8c7d, flags DONT_FRAGMENT
00:08:29:451383: ip4-punt
IPSEC_ESP: 20.20.99.215 -> 20.20.99.99
tos 0x00, ttl 64, length 152, checksum 0xbe54 dscp CS0 ecn NON_ECN
fragment id 0x8c7d, flags DONT_FRAGMENT
00:08:29:451384: error-punt
rx:VirtualFuncEthernet0/7/0.1556
00:08:29:451386: punt
* ip4-local: unknown ip protocol*
On Mon, Mar 8, 2021 at 2:00 AM Vijay Kumar via lists.fd.io <vjkumar2003=
gmail....@lists.fd.io> wrote:
> Hi,
>
> Strongswan <======================> [VPP IPSec] + [Azure IKE stack]
>
> I have a use case like above. Strongswan is the peer while VPP is the
> responder. On the right hand side, I am not showing VPP ikev2 plugin
> because we have disabled the plugin but rather using the Microsoft Azure
> ike stack. In our case the ike stack and vpp run on different pods. We have
> written a new plugin for IKE pkt forwarding to the pod where IKE stack is
> running. The new plugin registers for udp port 500 and 4500 and thus fwds
> all the received IKE traffic to IKE stack (to be precise, the new VPP
> plugin forwards IKE packets to the application process via memif. The
> application process in turn uses REST API to forward the IKE pkts to the
> pods that runs the IKE stack). Once SA is established, the IKE stack would
> install the SA on to the VPP IPSec plugin using VPP APIs (we would use
> the vl_api_rpc_call_main_thread function call to execute the REST API SA
> information).
>
> The *IPSec SA is established fine* as displayed below but ping to the
> host on the strongswan side is failing as "*blackholed packets*"
>
> CLIs logs
> ================
> vpp# show ipsec sa
> [0] sa 256349522 (0xf479552) spi 3475331116 (0xcf25582c) protocol:esp
> flags:[anti-replay ]
> [1] sa 256349523 (0xf479553) spi 305419899 (0x1234567b) protocol:esp
> flags:[anti-replay inbound ]
> vpp#
>
> NOTE
> =============
> 20.200.75.1 is the host on the strongswan side,
> while VirtualFuncEthernet0/7/0.1556 is the interface that is connected to
> the Strongswan (this interface is pingable with the SS interface)
>
> vpp# show interface
> Name Idx State MTU (L3/IP4/IP6/MPLS) Counter
> Count
> VirtualFuncEthernet0/7/0 3 up 1500/0/0/0 rx
> packets 12
> rx
> bytes 2432
> tx
> packets 12
> tx
> bytes 2408
> drops
> 8
> VirtualFuncEthernet0/7/0.1556 14 up 1500/0/0/0 rx
> packets 30
> rx
> bytes 647112
> tx
> packets 12
> tx
> bytes 2408
> drops
> 8
> ip4
> 8
> VirtualFuncEthernet0/9/0 4 down 9000/0/0/0
> ipip0 18 down 9000/0/0/0
> local0 0 down 0/0/0/0
>
>
> vpp# set interface ip address ipip0 20.200.76.2/32
> vpp# set interface state ipip0 up
> vpp# ip route add 20.200.75.1/32 via ipip0
> vpp# set interface unnumbered ipip0 use VirtualFuncEthernet0/7/0.1556
>
> vpp# show interface
> Name Idx State MTU (L3/IP4/IP6/MPLS)
> Counter Count
> VirtualFuncEthernet0/7/0 3 up 1500/0/0/0 rx
> packets 14
> rx
> bytes 2618
> tx
> packets 14
> tx
> bytes 2594
> drops
> 9
> VirtualFuncEthernet0/7/0.1556 14 up 1500/0/0/0 rx
> packets 34
> rx
> bytes 711766
> tx
> packets 14
> tx
> bytes 2594
> drops
> 9
> ip4
> 9
> VirtualFuncEthernet0/9/0 4 down 9000/0/0/0
> ipip0 18 up 9000/0/0/0
> local0 0 down 0/0/0/0
>
>
> *ISSUE*
> *=========*
> All the ping traffic from SS are coming to VPP as ESP packets but the VPP
> is dropping them as "*unknown ip protocol*". Also, for all the ping
> packets triggered from VPP side are not being put onto the ipip0 IPSec
> tunnel but they are dropped as "*blackholed packets*"
>
> *NOTE: -*
> *==============*
> On the VPP, after adding a route to the destination 20.200.75.1, the show
> ip FIB output shows dpo-drop rather than send via
> "VirtualFuncEthernet0/7/0.1556" as shown below.
>
>
> *vpp# show if fib*
>
>
>
>
>
> *20.200.75.1/32 <http://20.200.75.1/32> unicast-ip4-chain [@0]:
> dpo-load-balance: [proto:ip4 index:81 buckets:1 uRPF:109 to:[0:0]] [0]
> [@6]: ipv4 via 0.0.0.0 ipip0: mtu:9000 next:16
> 450000000000000040048b9814146363141463d7 stacked-on entry:78:
> [@1]: dpo-drop ip4*
>
>
> vpp# show node counters
> Count Node Reason
> * 10 null-node blackholed packets*
> 81 memif-input not ip packet
> 2731 an_ppe_wfectrl wfectrl packets received
> 2731 an_ppe_wfectrl wfectrl replies sent
> 2181 an_ppe_wfectrl session stat request
> received
> 1 an_ppe_wfectrl service construct config
> request received
> 1 an_ppe_wfectrl service construct config
> request success
> 1 an_ppe_wfectrl service config request
> received
> 1 an_ppe_wfectrl service config request
> success
> 453 an_ppe_wfectrl dpi stats request
> received
> 453 an_ppe_wfectrl dpi stats request success
> 19 an_ppe_wfectrl nat stats request
> received
> 19 an_ppe_wfectrl nat stats request success
> 58 arp-reply ARP replies sent
> 81 ip4-udp-lookup No error
> * 14 ip4-local unknown ip protocol*
> vpp#
> vpp#
>
>
> *NOTE*
> *=============*
> When I did a POC using VPP ikev2 plugin and VPP IPSec, I did not face this
> issue. The ping traffic from SS would be successfully decrypted at VPP and
> also the reply sent back to SS. In the POC, the route entry of the
> destination was fine. It was not dpo-drop.
>
>
> Please suggest if there is any way to debug the traffic drops as "Unknown
> ip protocol" for incoming ESP traffic and traffic drops as "blackholed
> packets" for outgoing traffic
>
> Any help is highly appreciated.
>
>
> Regards,
> Vijay Kumar N
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18880): https://lists.fd.io/g/vpp-dev/message/18880
Mute This Topic: https://lists.fd.io/mt/81158278/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
