On Tue, Dec 6, 2022 at 1:42 PM David Ahern <dsahern@xxxxxxxxx> wrote: > > On 12/6/22 1:36 PM, team lnx wrote: > > On Tue, Dec 6, 2022 at 12:10 PM David Ahern <dsahern@xxxxxxxxx> wrote: > >> > >> On 12/6/22 9:43 AM, team lnx wrote: > >>> Hello, > >>> > >>> I am a beginner for xdp and following is the setup > >>> > >>> 3rd party Board - (64 bit arch): This has 2 ethernet interfaces > >>> supporting XDP (v0 and v1) > >>> Host machine: Ubuntu > >>> > >>> step 1: 3rd party Board <-----connected over ethernet (v0) ------> Host - Ubuntu > >>> step 2: echo "1" > /proc/sys/net/ipv4/ip_forward > >>> step 3: Assign static ip address for v0 and v1 > >>> step 4: run: xdp_fwd -D v0 v1 on 3rd party Board > >>> step 5: start ping from host to v0 of 3rd party Board with expectation > >>> of forwarding from v0 to v1 > >>> > >>> Observation : In the above experiment I see xdp_fwd has a return code > >>> always set to XDP_PASS and when I traced it found that below > >>> conditions is the reason > >>> in net/core/filter.c > >>> if (res.type != RTN_UNICAST) { > >>> return BPF_FIB_LKUP_RET_NOT_FWDED; > >>> } > >>> > >>> 1. Could you please help in understanding the reason behind this ? > >> > >> RTN_LOCAL means delivery to a local process -- ie., nothing to forward > >> to another device / host. > >> > >> RTN_MULTICAST and RTN_BROADCAST: broadcast is not supported. Multicast > >> ... I forget how to use that. The fib lookup and xdp_fwd test predates > >> multicast support > >> > >> > >>> 2. Once #1 is resolved, do we need to add manually arp table/neighbor > >>> information as well ? > >>> > >> > >> the xdp_fwd app is a demo. In a production deployment, you will need to > >> have something manage the neighbor entries for hosts. e.g., look at `ip > >> neigh ... managed` if you have a new enough kernel. > >> > > > > Thanks for the response, > > Understood #2, but for #1 > > I have initiated ping from Host (ubuntu) -> V0 (ethernet) of 3rd party > > board with intention of forwarding/redirecting to V1 on the same board > > > > But I see XDP_PASS being returned instead of XDP_REDIRECT, anything > > missing/wrong in steps ? > > > > look at the return code from the fib_lookup. It indicates why the lookup > failed if it does not return BPF_FIB_LKUP_RET_SUCCESS: > > enum { > BPF_FIB_LKUP_RET_SUCCESS, /* lookup successful */ > BPF_FIB_LKUP_RET_BLACKHOLE, /* dest is blackholed; can be > dropped */ > BPF_FIB_LKUP_RET_UNREACHABLE, /* dest is unreachable; can be > dropped */ > BPF_FIB_LKUP_RET_PROHIBIT, /* dest not allowed; can be > dropped */ > BPF_FIB_LKUP_RET_NOT_FWDED, /* packet is not forwarded */ > BPF_FIB_LKUP_RET_FWD_DISABLED, /* fwding is not enabled on > ingress */ > BPF_FIB_LKUP_RET_UNSUPP_LWT, /* fwd requires encapsulation */ > BPF_FIB_LKUP_RET_NO_NEIGH, /* no neighbor entry for nh */ > BPF_FIB_LKUP_RET_FRAG_NEEDED, /* fragmentation required to fwd */ > }; > > Sure, I did search for it and read some article but found that BPF_FIB_LKUP_RET_NOT_FWDED means packets are not forwarded and only unicast are forwarded. Verified prog id and map id using bpftool to confirm if it has any issue interface details: prog/xdp id: 4 map_ids: 1 btf_id: 7 ./bpftool map show id 1 1: devmap name xdp_tx_ports flags 0x80 Any hints or suggestions on debugging this issue would be helpful ! Thanks
![]() |