Hi Satish, From the error counters lower, it seems that ip local is not the one to drop the packets. Also, if the packet is not tcp or udp, checksum should not computed, as per ip4_local_check_l4_csum [1]. Also, packets that fail the source ip check should be dropped with IP4_ERROR_SPOOFED_LOCAL_PACKETS or IP4_ERROR_SRC_LOOKUP_MISS.
So, to clear this up, could you attach gdb to your vpp (preferably compiled with debug symbols), breakpoint ip4_local_set_next_and_error and figure out if next for your packets is set correctly? Hope this helps, Florin [1] Note that I’m using master code as a reference not 18.10 code > On Apr 11, 2019, at 8:04 AM, satish.gu...@gmail.com wrote: > > Hi VPP-Dev, > > We recently moved to 1810 from 1801 and found the following issue. > Is this a known issue (or) any help on whats happening here ? > > 1. We are using memif in IP mode. > 2. Some Control plane process sends message over MEMIF to VPP process ( memif > mode = IP ) > 3. We are using a custom ip-proto value of 222 and tapping these packets in a > separate graph node on VPP side. > 4. This has been working fine till 1801. > 5. When we moved to 1810, the packet is getting dropped in ip4-local with > reason as "blackholed packets" > 6. When we looked at the code, this drop can happen in the following reasons > - SRC-IP invalid > - TCP/UDP checksum wrong > > 7. The FIB contains the SRC-IP subnet. Hence, SRC-IP error might not be the > reason > 8. We are suspecting that this drop is due to TCP/UDP csum. > > But, when the ip-proto is non-UDP-TCP, ideally this packet should have gone > to the next layer bypassing all these checks. > > Following is the packet trace / show output and fib details > > === > ##) > vpp# show node counters > Count Node Reason > 2 null-node blackholed packets > > ##) > vpp# show trace > > Packet 1 > > 00:48:08:119264: memif-input > memif: hw_if_index 3 next-index 0 > slot: ring 0 > 00:48:08:119354: ip4-input-no-checksum > unknown 222: 192.168.1.2 -> 192.168.1.1 > tos 0x00, ttl 64, length 10020, checksum 0xcfbe > fragment id 0x0000 > 00:48:08:120320: ip4-lookup > fib 0 dpo-idx 5 flow hash: 0x00000000 > unknown 222: 192.168.1.2 -> 192.168.1.1 > tos 0x00, ttl 64, length 10020, checksum 0xcfbe > fragment id 0x0000 > 00:48:08:120331: ip4-local > unknown 222: 192.168.1.2 -> 192.168.1.1 > tos 0x00, ttl 64, length 10020, checksum 0xcfbe > fragment id 0x0000 > > ##) > > vpp# show ip fib > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] > locks:[src:plugin-hi:2, src:default-route:1, ] > 192.168.1.0/32 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:9 to:[0:0]] > [0] [@0]: dpo-drop ip4 > 192.168.1.0/24 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:12 to:[0:0]] > [0] [@5]: ipv4 via 0.0.0.0 memif0/0: mtu:9000 > 192.168.1.1/32 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:13 to:[1:10020]] > [0] [@2]: dpo-receive: 192.168.1.1 on memif0/0 > 192.168.1.255/32 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:11 to:[0:0]] > [0] [@0]: dpo-drop ip4 > > ==== > > Also, is there anyway to get the exact sub-error-code which indicates that > this is due to TCP/UDP checksum error etc ? > Appreciate any inputs in this regard. > > Thanks & Regards, > Satish > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#12765): https://lists.fd.io/g/vpp-dev/message/12765 > Mute This Topic: https://lists.fd.io/mt/31031696/675152 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [fcoras.li...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12766): https://lists.fd.io/g/vpp-dev/message/12766 Mute This Topic: https://lists.fd.io/mt/31031696/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
