Hi Dinesh, probably the easiest should be to add your own node on the ip4-unicast feature arc. You can then eg. steer your packet to ip4-lookup to bypass ip4-options.
Best ben ________________________________________ From: [email protected] <[email protected]> on behalf of Dinesh via lists.fd.io <[email protected]> Sent: Wednesday, November 12, 2025 6:58 To: [email protected] Subject: Re: [vpp-dev] Issue: VPP parsing custom IPv4 header extensions as IP options Hi, Does anyone has idea about this ? On 10/11/25 16:23, Dinesh wrote: > Hi everyone, > > I have a requirement for adding a small custom header inside the > ip header in my VPP plugin which is of 8 bytes. > > In my implementation, i increased ihl value to 7 from 5. > > This works as expected in Linux kernel module, but where as in VPP > when the IHL > 5, the packet is automatically sent to the ip4-options > node, and my custom bytes are parsed as IP options (which leads to punt). > > Is there any recommeneded way to: > > 1. Allow packets with the extended ip header to bypass the > ip4-options node, or > > 2. Treat the additional bytes as a custom extension instead of IP > options ? > > Below is the example trace i am sharing. > > IP4: 00:15:17:e7:81:be -> 00:90:27:e3:02:26 > IPSEC_ESP: 14.14.14.2 -> 19.19.19.2 > tos 0x00, ttl 254, length 152, checksum 0x7a0f dscp CS0 ecn NON_ECN > fragment id 0x0000 > 00:15:34:949021: ethernet-input > frame: flags 0x3, hw-if-index 2, sw-if-index 2 > IP4: 00:15:17:e7:81:be -> 00:90:27:e3:02:26 > 00:15:34:949024: ip4-input-no-checksum > IPSEC_ESP: 14.14.14.2 -> 19.19.19.2 > tos 0x00, ttl 254, length 152, checksum 0x7a0f dscp CS0 ecn NON_ECN > fragment id 0x0000 > 00:15:34:949025: ip4-full-reassembly-feature > passthrough - not a fragment > 00:15:34:949026: fatpipe-worker-handoff > FATPIPE_WORKER_HANDOFF: next-worker 2 trace index 3 > 00:15:34:949031: fatpipe-input-ip4 > fatpipe-index:1 lb-index:0 > 00:15:34:949035: ipsec4-input-feature > IPSEC_ESP: sa_id 3 type: 0 spd 1 policy 10 spi 3353440098 > (0xc7e16f62) seq 9 > 00:15:34:949037: esp4-decrypt > esp: crypto aes-cbc-128 integrity sha1-96 pkt-seq 9 sa-seq 9 > sa-seq-hi 0 pkt-seq-hi 0 > 00:15:34:949047: ip4-input-no-checksum > ICMP: 192.168.250.1 -> 192.168.250.2 > version 4, header length 28 > tos 0x00, ttl 63, length 92, checksum 0xd7d1 dscp CS0 ecn NON_ECN > fragment id 0xb71b, flags DONT_FRAGMENT > ICMP echo_request checksum 0xafc7 id 23 > 00:15:34:949048: ip4-options > option:[0xc0,0xa8,0x64,0x2] > 00:15:34:949049: ip4-punt > fib:0 adj:0 flow:0x00000000 > ICMP: 192.168.250.1 -> 192.168.250.2 > version 4, header length 28 > tos 0x00, ttl 63, length 92, checksum 0xd7d1 dscp CS0 ecn NON_ECN > fragment id 0xb71b, flags DONT_FRAGMENT > ICMP echo_request checksum 0xafc7 id 23 > 00:15:34:949050: ip4-punt-redirect > via redirect:8 > 00:15:34:949051: ip4-dvr-dpo > sw_if_index:10 > 00:15:34:949051: ip4-dvr-reinject > sw_if_index:10 > 00:15:34:949052: tap4100-output > tap4100 flags 0x0319000d > > > Any guidance on how to handle this cleanly within the VPP graph > would be greatly appreciated. > > > Thanks, > Dinesh > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26513): https://lists.fd.io/g/vpp-dev/message/26513 Mute This Topic: https://lists.fd.io/mt/116217042/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
