Dinesh, Isn’t adding a new IPv4 option exactly what you are doing?
Note there’s quite a lot of: if ip[0] == 0x45 then drop Out there in the wild wild Internet. Cheers, Ole > On 12 Nov 2025, at 10:56, Benoit Ganne (bganne) via lists.fd.io > <[email protected]> wrote: > > 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 (#26514): https://lists.fd.io/g/vpp-dev/message/26514 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]] -=-=-=-=-=-=-=-=-=-=-=-
